Make Error responses optional about cti-taxii2 HOT 7 CLOSED

I may have been wrong to pull the HTTP 1.1 reference. HTTP/2 defers a lot of guidance to the HTTP 1.1 spec.

from cti-taxii2.

This seems reasonable, though I could also see an argument for it being a SHOULD.

from cti-taxii2.

I feel like any significant TAXII Server is going to have to sit behind a load balancer. It’ll be really difficult to handle the LB’s responses as JSON, especially in the Cloud. That’s why I’m hesitant to even use SHOULD.

from cti-taxii2.

This is in section 3.1. The text we are looking to change is:

TAXII responses with an HTTP error code (400-series and 500-series status codes, defined by sections 6.5 and 6.6 of [RFC7231]) that permit a response body (i.e. are not in response to a HEAD request) MUST contain an error message (see section 3.5.1) in the response body.

And we are looking to change the last MUST to be either a SHOULD or a MAY.

from cti-taxii2.

Does this also impact our Status Resource that is sent back with a 202 (Accepted) ?

from cti-taxii2.

No. It's not an error.

from cti-taxii2.

This changes was made in Section 3.1

Drew and I discussed this, and it seems like a MAY is the right way to go, since load balancers and cloud systems may need to do creative things with routing the error messages. The new text now says:

TAXII responses with an HTTP error code (400-series and 500-series status codes, defined by sections 6.5 and 6.6 of [RFC7231]) that permit a response body (i.e. are not in response to a HEAD request) MAY contain an error message (see section 3.5.1) in the response body.

from cti-taxii2.