All of the examples and resource definitions call out that the TAXII resources have a trailing slash. However, we forgot to add a normative statement saying as much. I propose we add a simple normative statement that says "All TAXII resources MUST have a trailing slash, as shown in their definitions." Or something like that.
The text was updated successfully, but these errors were encountered:
We discussed this on the working call on 2018-02-20 with the following 15 TC members (Bret Jordan, Trey Darley, Chris Ricard, Christian Hunt, Dan Dye, Dave Lemire, Drew Varner, Efrain Ortiz, Gary Katz, Jane Ginn, John-Mark Gurney, John Wunder, Nicholas Hayden, Paul Patrick, Rich Piazza).
There was no objection to adding a normative statement that says all resource endpoints MUST have a trailing slash.
I don't have any issues with this change, I wasn't at the plugfest where it came up.
I do think it will end up being a gotcha for some clients so we should make sure to have it in an FAQ. Many services just transparently deal with requests as if the trailing / doesn't matter, so clients get used to being imprecise. This will probably be exacerbated by some servers continuing to allow requests if the trailing slash is missing.
I don't think it's an RFC 7230 issue. It's just specified "3.1 Endpoints" table and elsewhere in TAXII 2.0 CS01 that way. I think the point is to clarify that the trailing / is a normative requirement.
My comment above
All TAXII endpoint URL paths MUST end in a trailing slash "/"
isn't meant to imply that RFC-7230 requires the /. I'm just trying to describe where the / belongs using terms describing a URL from RFC-7230, instead of "at the end of a resource". Specifically using "path" from 2.7. Uniform Resource Identifiers.
I'm fine w/ this, but at the same time, I'm a bit torn by requiring single item instances like fetching an object by it's UUID to us a trailing slash. Trailing slash indicates a directory, and that there is more than one "entity" under there.
But forcing all paths to end w/ a slash is easier and more consistent.
It is critical to remember that this is not a change from 2.0. This is the behavior that we all agreed to way back in 2.0 (it was originally requested by EclecticIQ from their API experience) and we tried to put it in the document, but found later, that we did not do a good enough job clarifying it. So this is all about adding the clarifying text.