search

oasis-tcs / cti-taxii2

OASIS CTI TC: An official CTI TC repository for TAXII 2 work
https://github.com/oasis-tcs/cti-taxii2
Other
9 stars 4 forks source link

How do we handle version based content negotiation #13

Closed jordan2175 closed 6 years ago

jordan2175 commented 7 years ago

If you only support say STIX 2.1 content and someone requests STIX 2.0 content, the spec says that you should return a 415 error code. When we wrote the spec, that seemed like a good things to do. However, I now feel like this is in error. This provides a terrible user experience

There should be some way of telling the client that you do not support STIX 2.0, but you DO have the content in STIX 2.1

gtback commented 7 years ago

I feel like the currently-specified behavior is correct. Clients that are able to process STIX 2.1 should include that in their Accept header.

We could add a clarifying note about this to the spec or to an implementer's guide.

MarkDavidson commented 7 years ago

When would a user (not a developer or API caller) experience the 415 as outlined in this scenario?

The most common case, I'd expect, is the user accessing a TAXII endpoint using a browser. We allow for that by allowing TAXII endpoints to support multiple media types, including HTML.

MarkDavidson commented 7 years ago

Clients have two options to remediate this option:

  1. Go to the manifest and view available media types
  2. Retry the request with a broader media type

Edit: This information is also present in the collections resource

MarkDavidson commented 7 years ago

Recommendation: Discuss if anything should be done, or if this is the desired state