Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discovery Resource Does not Clearly Articulate API Root Allowable Values #28

Closed
JasonKeirstead opened this issue Dec 18, 2017 · 9 comments

Comments

@JasonKeirstead
Copy link

Currently the specification is silent on if the URLs inside api_roots can be relative or not.

I would prefer that relative be allowed as it would make creating a modular TAXII service library simpler.... but regardless of the decision, we need to be clear here.

@JasonKeirstead
Copy link
Author

We also need the same clarity on the "default" property

@allant0
Copy link

allant0 commented Jan 23, 2018

Suggest we should also test this in future interop tests. The spec being silent to me means that it allows both and thats legitimate. Therefore we should include verification that for certain use cases in interop that we test it.

@jmgnc
Copy link

jmgnc commented Jan 23, 2018

I agree that we should support host relative URLs, but not path relative.. that is:
/foobar

is valid, and:
../foobar

is not valid...

The reason path relative should not be supported, is that it shouldn't be needed, as the api-root is at a well know location, and so the ../ will likely be a fixed prefix.

@jordan2175
Copy link

jordan2175 commented Jan 23, 2018

This was discussed on the working call on 2018-01-23 and the consensus was that this needs to be fixed / addressed, however, there is not yet a solid proposal for text on how to fix it, just that it needs to be fixed. The following people were on the working call: Bret Jordan, Trey Darley, John-Mark Gurney, Sarah Kelley, Chris Ricard, Dave Lemire, Jason Keirstead, Nicholas Hayden, Richard Struse, Sunil Ravipati.

@jordan2175
Copy link

At the F2F we discussed and have consensus that we need to allow both a Fully Qualified URL and an Host Based Absolute Path.

@jordan2175 jordan2175 changed the title Need clarity on if api_roots allows relative URLs Discovery Resource Does not Clearly Articulate API Root Allowable Values Feb 5, 2018
@jordan2175
Copy link

During interoperability testing, implementers discovered that the specification does not clearly specify the syntax for URL values. Implementations were evenly split between fully qualified URLs (e.g., https://example.com/api/1/) and URL paths (e.g., /api/1/).

At the Jan F2F is Salt Lake City, the consensus of the group was that both "Fully Qualified" URLs and "Absolute Path" URLs should be permitted, and clarifying text should be added to the specification. In large part, determining fully qualified URLs of hosted services is seen as prohibitively complex to implement. This is a backward compatible change.

The dissenting opinion is that the HTTP URL syntax is clearly defined, and that it requires the "fully qualified" form. The complexity of implementing fully qualified URLs is seen by some as overstated.

@jordan2175 jordan2175 added this to the TAXII-2.1-CSD01 milestone Feb 22, 2018
@jordan2175 jordan2175 added this to In progress in TAXII-2.1 Feb 22, 2018
@jordan2175
Copy link

jordan2175 commented Feb 27, 2018

We talked about this again on the working call on 2018-02-27 and the decision was to use full URLs and absolute paths that are absolute from the host, not relative to the discovery endpoint. @JasonKeirstead @jmgnc are going to contribute some text for the document.

@jordan2175
Copy link

I added text to section 4.1.1 API_Roots property description. The description now reads:

A list of URLs that identify known API Roots. This list MAY be filtered on a per-client basis.

API Root URLs MUST be HTTPS absolute URLs or relative URLs. API Root relative URLs MUST begin with a single / character and MUST NOT begin with // or '../". API Root URLs MUST NOT contain a URL query component.

Examples - Valid
https://taxii.example.com:443/
https://someserver.example.net/apiroot1/
/someapiroot/

Examples -Invalid
//someserver.example.com/apiroot1
../someapiroot/
https://foo.edu/bar?baz

@varnerac
Copy link

LGTM

@jordan2175 jordan2175 moved this from In progress to Done in TAXII-2.1 Apr 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
TAXII-2.1
  
Done
Development

No branches or pull requests

5 participants