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

MIMEAccept doesn't respect specificity #458

Closed
dougblack opened this issue Nov 5, 2013 · 7 comments · Fixed by #1574
Closed

MIMEAccept doesn't respect specificity #458

dougblack opened this issue Nov 5, 2013 · 7 comments · Fixed by #1574
Labels
Milestone

Comments

@dougblack
Copy link

@dougblack dougblack commented Nov 5, 2013

Hello!

I've been using the helpful MIMEAccept class in werkzeug.datastructures and I noticed that while it does respect quality, it doesn't respect specificity as outlined in RFC 2616.

Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies to a given type, the most specific reference has precedence. For example,

Accept: text/, text/html, text/html;level=1, */
have the following precedence:

  1. text/html;level=1
  2. text/html
  3. text/*
  4. /

Is this something that people are interested in seeing fixed? I'd be happy to open a pull.

@dave-shawley
Copy link

@dave-shawley dave-shawley commented Sep 2, 2014

👍 I just noticed this as well. The _accept_re in http.py does not take in to account media type parameters

@untitaker
Copy link
Member

@untitaker untitaker commented Sep 2, 2014

#205 is kind-of related.

@untitaker
Copy link
Member

@untitaker untitaker commented Sep 4, 2014

What is prioritized -- quality or specificity?

@jessaustin
Copy link
Contributor

@jessaustin jessaustin commented Sep 4, 2014

Can we agree that even though _accept_re now notices media type parameters, they should still be treated as opaque, so that one set of parameters isn't considered more specific than another (non-empty) set? If application code wants to examine these it's welcome to do so.

@untitaker
Copy link
Member

@untitaker untitaker commented Sep 4, 2014

The regex can't do much about this. This is supposed to be fixed in MIMEAccept.__init__, where the sorting happens. I'm currently working on it, but i have two questions: The one written above, and how specificity is defined.

@untitaker untitaker added the bug label Sep 4, 2014
@jessaustin
Copy link
Contributor

@jessaustin jessaustin commented Sep 4, 2014

As I understand it, specificity only governs how a representation with a particular media type is associated with a particular media range. So the server application should assign each representation of the current resource it can possibly send to one particular range that was sent in the Accept header, if it can. (If none of the possible representations fits into any of the specified media ranges, the server may 406 or arbitrarily pick a representation.) Specificity in this case means that any particular representation should go in the most specific range that includes that representation.

Quality/weight is only used after that assignment is done. It could have the result of a representation that had a less specific match having a higher quality and being chosen. If so, that's just what the client requested, e.g. Accept: text/*, text/html;q=0.5 would result in a text/plain representation being sent instead of a text/html representation, if the server application supports both plain text and html.

I just realized that if more than one representation is assigned to the "winning" range, the server application still has to arbitrarily pick one. Oh, well.

@untitaker
Copy link
Member

@untitaker untitaker commented Sep 4, 2014

As for a previous comment of mine:

This is supposed to be fixed in MIMEAccept.init, where the sorting happens

After trying to implement specificity, i don't think anymore this could be done there.

johnzeringue added a commit to johnzeringue/werkzeug that referenced this issue May 31, 2019
Previously, we didn't parse MIME parameters or use them to match or
prioritize content types. Now, we'll normalize and compare MIME
parameters and consider a MIME type with parameters higher priority than
one without them.

Fixes pallets#458
johnzeringue added a commit to johnzeringue/werkzeug that referenced this issue May 31, 2019
Previously, we didn't parse MIME parameters or use them to match or
prioritize content types. Now, we'll normalize and compare MIME
parameters and consider a MIME type with parameters higher priority than
one without them.

Fixes pallets#458
johnzeringue added a commit to johnzeringue/werkzeug that referenced this issue May 31, 2019
Previously, we didn't parse MIME parameters or use them to match or
prioritize content types. Now, we'll normalize and compare MIME
parameters and consider a MIME type with parameters higher priority than
one without them.

Fixes pallets#458
davidism pushed a commit to johnzeringue/werkzeug that referenced this issue Jul 14, 2019
Previously, we didn't parse MIME parameters or use them to match or
prioritize content types. Now, we'll normalize and compare MIME
parameters and consider a MIME type with parameters higher priority than
one without them.

Fixes pallets#458
@davidism davidism added this to the 1.0.0 milestone Jul 14, 2019
davidism pushed a commit to johnzeringue/werkzeug that referenced this issue Sep 5, 2019
Previously, we didn't parse MIME parameters or use them to match or
prioritize content types. Now, we'll normalize and compare MIME
parameters and consider a MIME type with parameters higher priority than
one without them.

Fixes pallets#458
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants