-
Notifications
You must be signed in to change notification settings - Fork 190
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
WebOb's MIMEAccept does follow standards for best_match(), but provides results that are less than satisfactory #239
Comments
To the RFC's we go...Well, it would be nice if for a change we had a standard that was sane and was fully specced out, but unfortunately we don't get nearly that lucky. https://tools.ietf.org/html/rfc7231#page-38 RFC7231 5.3.2 Accept is the RFC for this, and it states:
Which has Here's another example:
Which states:
This could mean that given the following:
It is acceptable to respond with Prior ArtApache HTTPD, this thing has or currently probably implements most of the various specs, including all those fun experimental ones. Specifically RFC2295: Transparent Content Negotiation in HTTP and RFC2296: HTTP Remote Variant Selection Algorithm -- RVSA/1.0 It's called It has two methods, one if the browser supports RFC2295 and RFC2296, but otherwise it has what it calls:
I am more interested in server driven negotiation, because we want WebOb to choose a best match, we have no interest in involving the client, and RFC2295/2296 can be implemented on top of WebOb. Apache implements the following dimensions, so I had to dig through the source code here: https://github.com/apache/httpd/blob/8322599c746bbdf1410a098a5d4764499baf7670/modules/mappers/mod_negotiation.c to get a handle on what it is doing. I am simplifying this down to just dealing with mime accept:
Given: Accept header: It too would return ConclusionI was wrong, It's not busted, but doesn't exactly return results that make a lot of sense to a human being that is looking at it. Unfortunately the spec doesn't provide enough information to state which is the correct answer. I personally consider the first one mentioned in the the quoted text " Browsers for example send a default header for general purpose requests that look similar to:
If the server offered the content in both If instead of looping by server variant we looped by client accept:
We would end up with |
Adding a simple
|
So I just figured out that MIMEAccept in WebOb returns results that while valid according to the standard feel like they are off...
Accept header:
application/json, text/html, */*;q=0.8
Server offers the following variants:
text/plain, text/html, application/json
Current
MIMEAccept.best_match()
will returntext/html
, even thoughapplication/json
is preferred by the client since it is listed first. This is because we currently use the server variants as the definitive list.The text was updated successfully, but these errors were encountered: