TAXII Services should display helpful (for humans) HTTP Responses

[MarkDavidson]

Right now, attempts to access TAXII Services result in an HTTP 406 (or similar) error, which isn't entirely useful for a human operator, especially one who is new to TAXII/django-taxii-services.

Perhaps a more useful HTTP response could be displayed - something along the lines of "This is a TAXII Service and it looks like you're attempting to access it with a browser. That's not going to work!" (Would detection based on the user-agent string be useful? I'm not sure - just throwing stuff out there).

-Mark

[gtback]

Can we customize the body of the HTTP response in the case of an HTTP 406? I wouldn't try to mess with user-agent detection.

[MarkDavidson]

Current Behavior

Doing a quick triage of HTTP Status Codes and what django-taxii-services responds with. Note that this describes current behavior, not ideal or target behavior.

• HTTP 200 OK - Anything containing a TAXII Message (including Status Messages indicating an error condition). This means everything "worked" at the HTTP/HTTPS layer and that the TAXII Message should be inspected.
• HTTP 406 Not Acceptable - Seems to occur in only one place [1], happens when the HTTP Accept Header specifies something the server can't generate (this is currently a hardcoded value, which should probably be modified)

More discussion

It looks like django-taxii-services doesn't really do header validation the way the Specifications describe.

• HTTP 406 (Unacceptable) should be generated in all cases where the Accept header specifies an unacceptable value. Currently, django-taxii-services only does so in certain circumstances (as noted).
• HTTP 415 (Unsupported Media Type) should be generated in all cases where the Content-Type header specifies an unsupported value. Currently, django-taxii-services does not do this.

For certain types of errors (e.g., an unacceptable X-TAXII-Accept header), the TAXII Specification doesn't prescribe a behavior. I feel this is a gap in the TAXII Specifications, and have added an issue: https://github.com/TAXIIProject/TAXII-Specifications/issues/49. However, that leaves us to decide what to do about the following situations:

• An unacceptable X-TAXII-Accept header
• An unsupported X-TAXII-Content-Type header
• An unsupported or invalid X-TAXII-Protocol header
• An unsupported or invalid X-TAXII-Services header

[1] https://github.com/TAXIIProject/django-taxii-services/blob/master/taxii_services/middleware.py#L38

[gtback]

I realize that the TAXII specifications state that TAXII errors should in general always be 200 messages, but I still disagree that This means everything "worked" at the HTTP/HTTPS layer is the right interpretation for how to use HTTP response status codes. TAXII error conditions (regardless of whether they are caused by HTTP headers or TAXII payload) should be 4XX errors, or possibly 5XX errors in some cases. In any case, the TAXII status message can be returned in the HTTP response body. </rant>

For now, I would say the best thing to do is return a 400 (Bad Request) for any invalid TAXII headers (the items that still need discussion). After that, we can discuss if more specific 4XX error codes are more appropriate.