-
Notifications
You must be signed in to change notification settings - Fork 5
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
Specify the realisation order of precedence for conflicting profile negotiation situations #2
Comments
What do you suggest? |
I suggest a principle and then we have to work out the details. The principle is: the more deliberately implemented realisation should win. So, QSA over HTTP (as QSA is a fixed thing, HTTP could be auto-set by a server). I can’t yet decide about QSA v. REST. In the REST test I’m now doing, there are more fixed ways of specifying a profile but no option for preferences, unlike HTTP & QSA. So perhaps REST over QSA. I will add test examples here to debate. |
Can you elaborate a bit on what you mean by REST in this case? To me QSA is a REST implementation (you simply ask for a specific resource and get a representation of the current state of that resource). |
Sure: there's the possibility to use RESTful resource URIs without QSAs, for example you could implement "list profiles" for So a simple pattern of The main thing to sort out with this URI-only approach is to order the /dimension/dimension_token pairs. Should it be:
or perhaps another order? The order should perhaps follow processing order so that would imply:
But I don't know enough about language, time (I think Memento says it's first?) etc. Obviously this purely hierarchical approach is limited compared to HTTP & QSA as it's hard to see sensible URIs doing the equivalent to:
But loads of sites use, for example, /en/ for English representations of things so I think it's sensible to cater for this. |
I really don't think we should be specifying this stuff. This is system architecture that should be left to system designers. |
@agreiner scripsit:
I see your point, My gut feeling is that usually a very specific URL trumps anything that HTTP headers say (so if you ask for Can you think of other cases? |
I think that you get data-prof1.csv if you request /data/prof-1.csv or /data.csv?profile=prof1 or whatever, unless the owner happened to set up content negotiation for /data/prof-1.csv or data.csv. Why anyone would set that up is beyond me, and seems such an unusual edge case that I think it should just follow the rules of currently available content negotiation. I see no reason to request a departure from that standard. |
@agreiner I don't understand "departure from the standard". Currently there is no standard for conflicting profile negotiation situations since there never has been the ability to request things on a profile basis. If we look to Media Type as an indication of what profile handing could look like, then, as Lars said, blah.csv with Accept: text/turtle should probably return CSV, since a deliberate human choice has been mad for CSV, as opposed to the less visible, machine-set, text/turtle. The triple conflict would be: /a/resource.csv?_mediatype=text/turtle Accept: text/xml. Here, I suggest,.csv should win over Accept: text/xml but _mediatype should win over .csv (a Query String Arg being even more deliberately set than a file extension-like URI). |
@nicholascar I meant that we should follow the approach used in content negotiation by media type when someone requests a resource with a specific media type in the URI while having accept headers in place. Of course, that would only come into play when the site admin has set up alternative representations for the URI in question, which strikes me as a very odd thing to do. |
Normative guidance on servers' handling of HTTP header conflicts are given in Section Hypertext Transfer Protocol Headers. No guidance is yet given in either the HTTP or QSA Functions Profiles' sections to indicate how to resolve QSA + HTTP conflicting instructions. General guidance must be given as to how to resolve Functional Profile clashes. I suspect the server can just tell you which FP it is adhering to in it's response and then this will be a general solution. |
I think QSA should override Headers - clients tend to set Headers as defaults - but human agency to specify a profile explicitly via QSA in either data references or as choice in UI should override software defaults. |
@rob-metalinkage can you suggest a specific addition to the document? |
@rob-metalinkage scripsit:
I certainly support this view and would go even further to say that when any request URI (not only "human agency") trumps the HTTP headers sent with that request. So if I ask for http://example.org/foo.html and my headers say |
I'm not convinced that it's possible to assume a real conflict. Negotiation should only happen when a web server is configured to supply different versions of a resource depending on the header content. If someone wishes to configure their web server to differentiate multiple possible responses to a URL that happens to have a query string in it, why not let them do that? |
it only applies if the query string has a query parameter with the specific semantics of specifying profiles the client wishes. (if the server chooses to do - or already implements an API that does - QSA ). any other URL elements will get ignored. |
In pyLDAPI, the order is indeed (most important first): QSA > HTTP For Conneg (by Media Type) implemented by the australian Government Linked Data WG, we have: QSA > file-like endings > HTTP due to the assumption that if someone specifies _format=text/turtle, it should override .xml which should override Accept: text/html. |
Seeing no disagreement over primacy of QSA over HTTP headers, decision is ACTION-373 - Provide text for order of precedence (#505) |
I think this deserves some more thought. If we expect web server software to deal with conneg by AP in headers, it would fall to its makers to enable it to determine that a given request uses query strings and override any configuration that would allow for content negotiation on that URL. But would we want web server software to inspect every query string and determine that? What would be the consequences for performance? Is there precedent for the server to override configuration based on the specifics of a request like that? |
If you ask for a response from an OAI-PMH server, you will get it in XML, regardless of any There must be lots of APIs that ignore HTTP |
And of course we only provide a mechanism for servers that do behave this way - there is nothing to force all servers to do things this way - they can just implement HTTP profile of conneg-by-ap using URIs if they like - but at least this spec now provides a way to find out what they do actually support. |
Yes, I think most APIs ignore content negotiation, but the question is what to do when there is server configuration for http-header-based conneg and a web application that accepts query strings for the same resources. As the server, I'm thinking of web server software like Apache or nginx, not the web application. These handle content negotiation by directives in the configuration file. There would only ever be a conflict if someone creates a directive to use the headers for content negotiation and also accepts a query string for requesting data by profile. That seems obviously a developer error, and it would be most helpful if the web server handled it in a way that allowed the developer to guess what was going on, following the principle of least surprise. |
Thats a good analysis of an aspect of this issue - I would say that it would be appropriate for the server to respect the query string - and return a response saying that profile is not found. in general I think you are correct if you are saying it would be a misconfiguration to attempt to support negotiation in the http server layer if the application wished to support QSA - the server should be configured to pass those headers to the application - thats certainly the way my implementation will operate. Do you think this needs to be explicitly stated though? It may be worthwhile stating that normal HTTP error responses should be used according to the reason a profile may not be available (including 404 but also access denied etc) - and if really necessary citing this as an example in the precedence section? |
I think the operative word here is "Web application". Admitting that I've only once confitgured an Apache server to use content negotiation (several years ago), my understanding at that time was that that configuration -- serving one specific path -- was only used for serving content from the file system (i. e. |
I think @larsgsvensson is correct with the statement about what Apache etc. could implement. I've configured many Apache servers for conneg, both for local file systems (conneg to serve HTML or RDF from different files, for example) and also as proxies to applications written in Python or applications on whole other servers. In those cases, Apache is just acting as a pass-through splitting requests, usually, on some path segment. The pass-through must convey all relevant Headers & QSAa to the application which then handles the response. I do use Apache to funnel multiple possible ways of requesting a resource using conneg into a single way that an application understands though in on server's case. e.g.:
So here you can request Turtle by either using the QSA _format=text/turtle or Accept: text/turtle or .ttl at the end of the resource. All result in a call to the Application of ?_format=text/turtle since the application can only handle QSAs. So logic similar to this in Apache could be used by developers for Conneg by P. |
The discussion here is now about implementation, not specification. I'm satisfied that the original issue has been dealt with by addition to text to ED Section 6.5 Order of Precedence for Implementation Profiles. |
I think it's okay to go with the QSA approach over HTTP headers, since handling query strings would have to be done by a separate web app, so the web server would know to hand it off without parsing anyway, and returning a 404 for a client request that assumes the wrong approach seems reasonable. Since we are allowing for alternative realizations, how does the order of precedence work with as-yet-unspecified ones? Maybe the only real conflict is between HTTP headers and web apps. When you say that "a client MAY specify conflicting choices via different mechanisms", I think you don't mean the RFC2119 version of "may" here. Maybe "In the case where a client requests one profile via one mechanism and another profile via a different mechanism, the order of precedence . . ." |
I don't think the use of MAY or the alternative suggested makes any difference! I think the sentence:
Is problematic since we can't force future Functional Profiles to respect other FP's claims to order of precedence. Also, there is no canonical mechanism for order of precedence so we can't test for MUST. After discussion in the subgroup, we feel that more discussion is needed about this issue so we will list it in the 3PWD. |
Have tweaked wording according to @agreiner point about MAY.. removed MUST and added link to this issue to help solicit feedback to check this. |
Add ref to #505 - order or precedence and remove MUST
It is clearly specified that QSA has precedence over HTTP if both are supported, however there is no proposed mechanism for specifying the relative precedence of other URL based implementations. Can this be left to implementations to specify or must the situation be handled in this specification?
The text was updated successfully, but these errors were encountered: