Ignore empty parts when parsing Content-Disposition header #11243
Conversation
PLPeeters
force-pushed
the
content-disposition-parsing-improvement
branch
from
fe116a2 to
b62024e
Compare
psf-chronographer
bot
added
the
bot:chronographer:provided
CodSpeed Performance ReportMerging #11243 will not alter performanceComparing Summary
|
Dreamsorcerer
added
the
backport-3.13
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #11243 +/- ##
==========================================
- Coverage 98.84% 98.84% -0.01%
==========================================
Files 131 131
Lines 43280 43293 +13
Branches 2328 2329 +1
==========================================
+ Hits 42782 42792 +10
- Misses 343 346 +3
Partials 155 155
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Backport to 3.13: 💚 backport PR created✅ Backport PR branch: Backported as #11248 🤖 @patchback |
(cherry picked from commit f01cb5e)
…ontent-Disposition header (#11248) **This is a backport of PR #11243 as merged into master (f01cb5e).** Co-authored-by: Pierre-Louis Peeters <[email protected]>
|
@Dreamsorcerer Any reason for not backporting to 3.12? Awesome to have a backport bot now, by the way 😁 |
Feels like a new feature to me, so not sure it makes sense to go to 3.12. I'm thinking we'll probably release 3.13 alongside Python 3.14 anyway.
We have for many years, it just hits conflicts with most PRs due to how far master has diverged. Got lucky on this one. |
From my point of view, it looks more like an improvement than a new feature since it didn't add anything. Your call of course, but I'd have immediate use for it being in 3.12; would be nice to avoid manual parsing. |
What do these changes do?
They make it so empty parts are ignored when parsing the
Content-Dispositionheader to avoid trivial parsing issues.Are there changes in behavior for the user?
Trivially correctible Content-Disposition headers will now be parsed instead of logging a warning and returning
None.Is it a substantial burden for the maintainers to support this?
No.
Related issue number
Fixes #5988
Checklist
CONTRIBUTORS.txtCHANGES/foldername it
<issue_or_pr_num>.<type>.rst(e.g.588.bugfix.rst)if you don't have an issue number, change it to the pull request
number after creating the PR
.bugfix: A bug fix for something the maintainers deemed animproper undesired behavior that got corrected to match
pre-agreed expectations.
.feature: A new behavior, public APIs. That sort of stuff..deprecation: A declaration of future API removals and breakingchanges in behavior.
.breaking: When something public is removed in a breaking way.Could be deprecated in an earlier release.
.doc: Notable updates to the documentation structure or buildprocess.
.packaging: Notes for downstreams about unobvious side effectsand tooling. Changes in the test invocation considerations and
runtime assumptions.
.contrib: Stuff that affects the contributor experience. e.g.Running tests, building the docs, setting up the development
environment.
.misc: Changes that are hard to assign to any of the abovecategories.
Make sure to use full sentences with correct case and punctuation,
for example:
Use the past tense or the present tense a non-imperative mood,
referring to what's changed compared to the last released version
of this project.