When matching which entry in the `Accept` header should be used for
a given media type, the specificity matters. However once those are
resolved, only the quality matters when selecting preference.
Regression in c075508b4de8edf9db553b409f8a8ed2f26ecead.
Thank you to Anders Kaseorg for the report.
Backport of 12c1557060fc94fe5e1fbddc4578a4e29d38f77c from main.
The "q" key was removed while addressing ticket #36411. Despite
`MediaType.params` is undocumented and considered internal, it was used
in third-party projects (Zulip reported breakage), so this work restored
the `q` key in `params`.
Thanks Anders Kaseorg for the report.
Regression in c075508b4de8edf9db553b409f8a8ed2f26ecead.
Backport of cf5f36bf903a2854f5e395149cee707115b83744 from main.
HttpRequest.get_preferred_type() did not account for parameters in
Accept header media types (e.g., "text/vcard; version=3.0"). This caused
incorrect content negotiation when multiple types differed only by
parameters, reducing specificity as per RFC 7231 section 5.3.2
(https://datatracker.ietf.org/doc/html/rfc7231.html#section-5.3.2).
This fix updates get_preferred_type() to treat media types with
parameters as distinct, allowing more precise and standards-compliant
matching.
Thanks to magicfelix for the report, and to David Sanders and Sarah
Boyce for the reviews.
Backport of c075508b4de8edf9db553b409f8a8ed2f26ecead from main.
