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

Sort order is not stable in Accept class #1686

Closed
lincolnq opened this issue Dec 27, 2019 · 2 comments · Fixed by #1701
Closed

Sort order is not stable in Accept class #1686

lincolnq opened this issue Dec 27, 2019 · 2 comments · Fixed by #1701
Milestone

Comments

@lincolnq
Copy link

@lincolnq lincolnq commented Dec 27, 2019

    from werkzeug.datastructures import LanguageAccept
    from werkzeug.http import parse_accept_header

    a = parse_accept_header("en-US,fr-FR", LanguageAccept)
    assert a.best == "en-US"  # fails, it returns fr-FR

I expected the order to be preserved.

RFC 3282 describes desired behavior for Accept-Language: "If no Q values are given, the language-ranges are given in priority order, with the leftmost language-range being the most preferred language; this is an extension to the HTTP/1.1 rules, but matches current practice."

Looking at the source code, the Accept class is reverse-sorting the input list by specificity, then quality, then name; I think it should not sort by name and instead should preserve the given order.

@zgoda
Copy link
Contributor

@zgoda zgoda commented Jan 1, 2020

According to current standard which is RFC 7231 I'd rather expect a list in case of equal preference matches. There is a note there describing this exact case.

@pgjones
Copy link
Member

@pgjones pgjones commented Jan 16, 2020

See #1701 - I also think the parsed order should be preserved.

@davidism davidism added this to the 1.0.0 milestone Jan 16, 2020
@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
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants