Bump python-multipart from 0.0.22 to 0.0.31#3112
Conversation
dependabot
Bot
added
dependencies
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM — routine Dependabot lockfile bump of python-multipart 0.0.22 → 0.0.31.
What was reviewed:
- The diff is confined to
uv.lock; thepyproject.tomlfloor (python-multipart>=0.0.9) is unchanged, so this only affects the SDK's own dev/CI environment, not downstream installs. - Checked the SDK's exposure to the release-note changes: python-multipart is used indirectly via starlette's
request.form()in the OAuth handlers (authorize,token,revoke,client_auth). The 0.0.30 urlencoded-separator change (only&splits fields) matches standard OAuth form encoding, and CI's test suite exercises these endpoints. - Verified the lock entry is a normal registry update (new sdist/wheel URLs + hashes from pypi.org).
Extended reasoning...
Overview
This is a Dependabot-generated PR that bumps python-multipart from 0.0.22 to 0.0.31 in uv.lock only. No source code, no pyproject.toml constraint, and no CI configuration is touched. The dependency floor remains >=0.0.9, consistent with the repo's guideline of not raising floors for upstream changes alone — this bump merely refreshes the pinned version used for the SDK's own locked environments.
Security risks
The upstream changes between 0.0.22 and 0.0.31 are largely hardening (bounded header field names, boundary-length cap, non-negative Content-Length validation, RFC 2231 parameter handling) plus performance work — net-positive from a security standpoint. The lock entry points at pypi.org with updated sha256 hashes for both sdist and wheel, which is the normal shape for a registry version bump; uv verifies these hashes at install time.
Level of scrutiny
Low. Lockfile-only dependency bumps are mechanical and reversible. The one behavior-relevant upstream change is 0.0.30's switch to treating only & as the urlencoded field separator (WHATWG-aligned). The SDK parses form bodies only in the OAuth handlers via starlette's request.form(), and OAuth 2.0 mandates standard &-separated application/x-www-form-urlencoded bodies, so this does not affect the SDK's behavior in practice.
Other factors
The bug hunting system found no issues, and the CI matrix (3.10–3.14 across platforms, locked and lowest-direct resolutions) exercises the form-parsing paths through the auth handler tests, which would surface any regression from the new version. No prior reviews or outstanding comments exist on this PR.
Bumps [python-multipart](https://github.com/Kludex/python-multipart) from 0.0.22 to 0.0.31. - [Release notes](https://github.com/Kludex/python-multipart/releases) - [Changelog](https://github.com/Kludex/python-multipart/blob/main/CHANGELOG.md) - [Commits](Kludex/python-multipart@0.0.22...0.0.31) --- updated-dependencies: - dependency-name: python-multipart dependency-version: 0.0.31 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
changed the title
8542a79 to
4526a21
Compare
There was a problem hiding this comment.
LGTM — routine Dependabot lockfile bump of python-multipart 0.0.22 → 0.0.31.
What was reviewed
- Only
uv.lockchanged; sdist/wheel hashes match the PyPI release and the version satisfies thepython-multipart>=0.0.9constraint inpyproject.toml. - The SDK never imports
python_multipartdirectly — it's used indirectly via Starlette form parsing — so upstream behavior changes (RFC 2231 handling, urlencoded separator, header limits) don't touch SDK code paths. - The included releases are hardening/perf fixes (header limits, boundary cap, negative Content-Length rejection) with no API removals affecting this repo.
Extended reasoning...
Overview
This PR is a Dependabot-generated bump of python-multipart from 0.0.22 to 0.0.31, touching only uv.lock. No source code, pyproject.toml constraints, or CI configuration are modified. The lockfile entry's new sdist and wheel URLs and SHA-256 hashes correspond to the official PyPI 0.0.31 release.
Security risks
None introduced by the SDK. The upstream changes are predominantly security hardening: multipart header size limits, a 256-byte boundary cap, bounding header field name size before validation, and rejecting negative Content-Length in parse_form. These reduce DoS surface rather than expand it. The dependency floor (>=0.0.9) is unchanged, consistent with the repo guideline of not raising floors for dependency fixes alone.
Level of scrutiny
Low. Lockfile-only dependency bumps within an existing version constraint are mechanical. The main check is whether upstream behavior changes could break SDK functionality: python_multipart is not imported anywhere in src/, so the SDK's exposure is limited to Starlette's optional form-parsing path, which the SDK's HTTP transports (JSON/SSE based) do not exercise. Parsing-behavior changes in 0.0.23–0.0.31 (WHATWG urlencoded separator, RFC 2231 extended-parameter handling) therefore don't affect SDK code.
Other factors
The bug hunting system found no issues, and the PR timeline has no outstanding reviewer comments. CI's full test matrix runs against the locked version, so any incompatibility would surface there. This fits squarely in the approvable category of simple, mechanical dependency updates.
Bumps python-multipart from 0.0.22 to 0.0.31.
Release notes
Sourced from python-multipart's releases.
... (truncated)
Changelog
Sourced from python-multipart's changelog.
Commits
4cffc68Version 0.0.31 (#298)c814948Reject negativeContent-Lengthinparse_form(#297)6b837d4Bound header field name size before validating (#296)e0c4f9dBump the github-actions group with 3 updates (#294)b8a01bbBump the python-packages group with 3 updates (#293)6732164Speed up multipart header parsing and callback dispatch (#295)9d3ead5Version 0.0.30 (#292)3506c15Ignore RFC 2231 extended parameters inparse_options_header(#291)d69df35Treat only&as the urlencoded field separator (#290)1e6ff97Bump idna from 3.11 to 3.15 (#289)