MIMEAccept doesn't respect specificity

[dougblack]

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]

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

[untitaker]

#205 is kind-of related.

[untitaker]

What is prioritized -- quality or specificity?

[jessaustin]

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]

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.

[jessaustin]

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]

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.