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

Prefer exact match without parameters to match with extra parameters. #1367

Closed
suola opened this issue Oct 14, 2018 · 4 comments · Fixed by #2348
Closed

Prefer exact match without parameters to match with extra parameters. #1367

suola opened this issue Oct 14, 2018 · 4 comments · Fixed by #2348

Comments

@suola
Copy link

suola commented Oct 14, 2018

If server supports both 'type/subtype' and 'type/subtype;param=foo', a request which accepts 'type/subtype' should be served with 'type/subtype'. Currently the extra parameter is not taken into account when determining the preference of the two types, and preference is selected by order of the types.

Relevant PR in mimeparse:

falconry/python-mimeparse#36

@vytas7
Copy link
Member

vytas7 commented Jul 17, 2020

Indeed, that sounds like a logical suggestion.

FWIW, we vendored python-mimeparse into Falcon as part of the 2.0 release as it was the last dependency.
In that light, a question arises what to do with your PR if we agree to go ahead with it. Maybe we should ask @dbtsai to take over maintenance of the project 🤔 Or whether we should fork our version.

@vytas7 vytas7 added this to the Version 3.x milestone Jul 17, 2020
@vytas7
Copy link
Member

vytas7 commented Jul 17, 2020

Note that I'm reluctant to label this as a breaking change, as we don't seem to provide exact guarantees how subtypes are chosen.

@vytas7
Copy link
Member

vytas7 commented Jul 18, 2020

Related:

@vytas7 vytas7 modified the milestones: Version 4.x, Version 4.0 Sep 30, 2024
vytas7 added a commit to vytas7/falcon that referenced this issue Oct 1, 2024
vytas7 added a commit that referenced this issue Oct 5, 2024
* feat: WiP reimplement mimeparse

* feat(mediatypes): add some skeletons for mediatype parsing

* chore: fix up after master merge

* feat(mimeparse): wip doodles

* feat(mediatypes): implement computation of best quality

* feat(mediatypes): remove vendored mimeparse

* docs: add a newsfragment for one of the issues

* refactor: remove debug `print()`s

* feat(mediatypes): add specialized mediatype/range errors, coverage

* docs(newsfragments): add a newsfragment for #1367

* test(mediatypes): add more tests

* feat(mediatypes): improve docstring, simplify behaviour

* refactor(mediatypes): use a stricter type annotation

* chore: remove an unused import

* chore: fix docstring style violation D205

* chore(docs): apply review suggestion to `docs/ext/rfc.py`

Co-authored-by: Federico Caselli <cfederico87@gmail.com>

* docs(newsfragments): apply review suggestion for `docs/_newsfragments/864.breakingchange.rst`

Co-authored-by: Federico Caselli <cfederico87@gmail.com>

* refactor(mediatypes): address some review comments

* perf(mediatypes): short-circuit if q is absent as per review comment

* docs: explain how to mitigate a potentially breaking change

* docs: add a note that we continue to maintain python-mimeparse

* refactor(mediatypes): convert _MediaType and _MediaRange to dataclasses

* fix(mediatypes): only use dataclass(slots=True) where supported (>=py310)

* refactor(mediatypes): a yet another attempt to make dataclasses work with __slots__

---------

Co-authored-by: Federico Caselli <cfederico87@gmail.com>
@vytas7
Copy link
Member

vytas7 commented Nov 10, 2024

@suola I know this has taken us a long time, but the issue has finally been fixed in 4.0.0.
See the description of the new algorithm here: falcon.mediatypes.quality().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants