Any "successful" non-TAXII response from a server will be wrapped in Status Message

[traut]

At the moment, libtaxii will wrap any "successful" HTTP response, parsed by get_message_from_http_response, into Status Message object with status FAILURE.

"Successful" responses are defined as anything that has a status code in success range and urllib2 thinks its ok (status code in range 100-299, https://docs.python.org/2/howto/urllib2.html#httperror).

In simple words, libtaxii can send a TAXII message to http://bing.com and return a valid TAXII response with HTML page wrapped in it!

This is extremely misleading and makes debugging difficult.

It also conflicts with the spec:

TAXII conformant senders MUST include the X-TAXII-Content-Type header when the entity body
contains a TAXII Message. Conversely, if the X-TAXII-Content-Type header is not present in an HTTP
Message, the recipient can assume that the message does not contain a TAXII Message. 

2.1.4 X-TAXII-Content-Type
http://taxii.mitre.org/specifications/version1.0/http1.0/TAXII_HTTPProtocolBinding_Specification.pdf

This is very critical issue in my opinion. Proper solution here is to raise a custom exception (InvalidMessageException?) and delegate a decision upstream, to the client.

// related to #181 and #175

[MarkDavidson]

@traut,

I agree with your points, and I have some thoughts on the matter.

Check out Section 5 of the TAXII HTTP Protocol Binding spec; the behavior you note is a result of implementing that section.

That said, there are a couple of points:

• First and foremost, is the text I referenced something that should change in a future revision of TAXII (as in the spec, not the software)?
• Second, the spec says SHOULD (not MUST), so there is freedom for implementations to choose what they want to do. One option is to have a flag along the lines of trap_http_errors=[True|False]. Developers could then switch on/off the default behavior for debugging.
• This is behavior that if changed, would (IMO) significantly change the API.

Thoughts?

Thank you.
-Mark

[traut]

@MarkDavidson thanks for the details.

I have mixed feelings about that section. As a suggestion how to treat HTTP Status Codes semantically, on a component level, it is great. Transport component (HTTP) replies with a Status Code and TAXII logic component treats it as failure/unauthorised/bad message event. The event should bubble up to business logic.

It seems to me that libtaxii here is in between transport layer and business logic. Translating that event into valid TAXII message can mask underlying issue.

When using libtaxii as a library inside an application (for example in Cabby), I would prefer to get libtaxii-specific exception raised instead of getting valid TAXII response object. Example: if there is a typo in discovery path and Status Code 404 is returned, application can act differently, than when TAXII server has internal error and Failure Status Message is returned.