Support httpx2 in the test client - #3291
Merged
Merged
Conversation
Prefer httpx2 in starlette.testclient, falling back to httpx with a StarletteDeprecationWarning. Existing httpx-only users keep working.
Owner
Author
|
Being a bit more transparent about this, instead of just the LLM generated description:
|
5 tasks
This was referenced May 26, 2026
Merged
|
Should the readme be updated to reflect the preference for httpx2? |
3 tasks
bod-zol
added a commit
to bod-zol/fastapi-easy-responses
that referenced
this pull request
Jun 22, 2026
- add httpx2 as dev dependency, because since starlette Kludex/starlette#3291 (version1.2.0) a warning is issued if the httpx2 module is unavailable for the TestClient - Kludex/starlette#3119 (v1.3.1) made this a more visible warning - parallelly in #14 I introduced to handle all warnings as errors in unit tests - these caused the tests to fail for this version bump
1 task
Open
5 tasks
t41372
added a commit
to standard-voice/standard_asr
that referenced
this pull request
Jul 16, 2026
…constraint The dev-only `[tool.uv] constraint-dependencies = ["starlette<1.0"]` pin held the lock at Starlette 0.52.1 and blocked five open Dependabot alerts (2 high, 2 medium, 1 low) — all Starlette, all fixed in Starlette >= 1.3.1. The pin existed only because Starlette's `TestClient` moved to the `httpx2` transport (Starlette 1.2.0, "Support httpx2 in the test client", Kludex/starlette#3291) while our FastAPI server tests still drove it through the classic `httpx`-based client. Migrate to the httpx2 transport and drop the constraint: - Dev dependency `httpx>=0.28` -> `httpx2>=2.0`; server-test response annotations `httpx.Response` -> `httpx2.Response` (tests/test_server.py). The TestClient surface is otherwise identical (httpx2 is Pydantic's fork of httpx), so the assertions are unchanged. - Raise the `fastapi` floor 0.118 -> 0.133 in both the `test` group and the `[server]` extra: fastapi 0.133 is the first release to drop its own `starlette<1.0.0` cap (0.132 still pins it), so it is the floor that admits the patched Starlette 1.x line and the floor the lower-bounds CI lane can verify. 0.133 subsumes the earlier 0.118 multipart-coercion floor. - Remove the two now-obsolete `filterwarnings` ignores (the httpx-transport and `app=` shortcut deprecations no longer fire under httpx2; `["error", ...]` proves it — the suite stays green with them gone). - Re-resolve the lock: Starlette 0.52.1 -> 1.3.1, httpx dropped, httpx2 2.5.0 and httpcore2 added, fastapi stays 0.136.3. Docs/config kept consistent: the advisory in docs/compatibility-advisories.md moves to "Resolved" (dated); the stale `starlette<1.0` example references in CONTRIBUTING.md and .github/dependabot.yml are updated. Gates: ruff clean, pyright strict 0 errors, pytest 1722 passed at 100% line+branch coverage (py3.13), and the lower-bounds floor stack (fastapi 0.133.0 + starlette 1.3.1 + httpx2 2.0.0, py3.10) passes the full suite.
t41372
added a commit
to standard-voice/standard_asr
that referenced
this pull request
Jul 16, 2026
…constraint The dev-only `[tool.uv] constraint-dependencies = ["starlette<1.0"]` pin held the lock at Starlette 0.52.1 and blocked five open Dependabot alerts (2 high, 2 medium, 1 low) — all Starlette, all fixed in Starlette >= 1.3.1. The pin existed only because Starlette's `TestClient` moved to the `httpx2` transport (Starlette 1.2.0, "Support httpx2 in the test client", Kludex/starlette#3291) while our FastAPI server tests still drove it through the classic `httpx`-based client. Migrate to the httpx2 transport and drop the constraint: - Dev dependency `httpx>=0.28` -> `httpx2>=2.0`; server-test response annotations `httpx.Response` -> `httpx2.Response` (tests/test_server.py). The TestClient surface is otherwise identical (httpx2 is Pydantic's fork of httpx), so the assertions are unchanged. - Security floors (the load-bearing rationale): all five GHSAs are fixed only on the Starlette 1.x line, with no 0.x backports, so `starlette>=1.3.1` is declared directly in the `[server]` extra as a fail-loud floor — an app pinning a vulnerable 0.x Starlette now gets a resolver error instead of a silently vulnerable server. The `fastapi` floor rises 0.118 -> 0.133 in both the `test` group and `[server]`: 0.133 is the first release to drop FastAPI's own `starlette<1.0.0` cap (0.132 still pins it), i.e. the lowest fastapi that can coexist with the patched line. It subsumes the earlier 0.118 multipart-coercion floor (kept as recorded history; today's lower-bounds lane resolves 0.133 and can no longer re-verify it). - Remove the two now-obsolete `filterwarnings` ignores (the httpx-transport and `app=` shortcut deprecations no longer fire under httpx2; `["error", ...]` proves it — the suite stays green with them gone). - Re-resolve the lock: Starlette 0.52.1 -> 1.3.1, httpx dropped, httpx2 2.5.0, httpcore2 2.5.0 and truststore added (httpx2's trust-store chain replaces certifi), fastapi stays 0.136.3. Docs/config kept consistent: the advisory in docs/compatibility-advisories.md moves to "Resolved" (dated); the stale `starlette<1.0` example references in CONTRIBUTING.md and .github/dependabot.yml are updated. Gates: ruff clean, pyright strict 0 errors, pytest 1722 passed at 100% line+branch coverage (py3.13), and the lower-bounds floor stack (fastapi 0.133.0 + starlette 1.3.1 + httpx2 2.0.0, py3.10) passes the full suite.
t41372
added a commit
to standard-voice/standard_asr
that referenced
this pull request
Aug 8, 2026
…constraint The dev-only `[tool.uv] constraint-dependencies = ["starlette<1.0"]` pin held the lock at Starlette 0.52.1 and blocked five open Dependabot alerts (2 high, 2 medium, 1 low) — all Starlette, all fixed in Starlette >= 1.3.1. The pin existed only because Starlette's `TestClient` moved to the `httpx2` transport (Starlette 1.2.0, "Support httpx2 in the test client", Kludex/starlette#3291) while our FastAPI server tests still drove it through the classic `httpx`-based client. Migrate to the httpx2 transport and drop the constraint: - Dev dependency `httpx>=0.28` -> `httpx2>=2.0`; server-test response annotations `httpx.Response` -> `httpx2.Response` (tests/test_server.py). The TestClient surface is otherwise identical (httpx2 is Pydantic's fork of httpx), so the assertions are unchanged. - Security floors (the load-bearing rationale): all five GHSAs are fixed only on the Starlette 1.x line, with no 0.x backports, so `starlette>=1.3.1` is declared directly in the `[server]` extra as a fail-loud floor — an app pinning a vulnerable 0.x Starlette now gets a resolver error instead of a silently vulnerable server. The `fastapi` floor rises 0.118 -> 0.133 in both the `test` group and `[server]`: 0.133 is the first release to drop FastAPI's own `starlette<1.0.0` cap (0.132 still pins it), i.e. the lowest fastapi that can coexist with the patched line. It subsumes the earlier 0.118 multipart-coercion floor (kept as recorded history; today's lower-bounds lane resolves 0.133 and can no longer re-verify it). - Remove the two now-obsolete `filterwarnings` ignores (the httpx-transport and `app=` shortcut deprecations no longer fire under httpx2; `["error", ...]` proves it — the suite stays green with them gone). - Re-resolve the lock: Starlette 0.52.1 -> 1.3.1, httpx dropped, httpx2 2.5.0, httpcore2 2.5.0 and truststore added (httpx2's trust-store chain replaces certifi), fastapi stays 0.136.3. Docs/config kept consistent: the advisory in docs/compatibility-advisories.md moves to "Resolved" (dated); the stale `starlette<1.0` example references in CONTRIBUTING.md and .github/dependabot.yml are updated. Gates: ruff clean, pyright strict 0 errors, pytest 1722 passed at 100% line+branch coverage (py3.13), and the lower-bounds floor stack (fastapi 0.133.0 + starlette 1.3.1 + httpx2 2.0.0, py3.10) passes the full suite.
t41372
added a commit
to standard-voice/standard_asr
that referenced
this pull request
Aug 8, 2026
…constraint (#40) The dev-only `[tool.uv] constraint-dependencies = ["starlette<1.0"]` pin held the lock at Starlette 0.52.1 and blocked five open Dependabot alerts (2 high, 2 medium, 1 low) — all Starlette, all fixed in Starlette >= 1.3.1. The pin existed only because Starlette's `TestClient` moved to the `httpx2` transport (Starlette 1.2.0, "Support httpx2 in the test client", Kludex/starlette#3291) while our FastAPI server tests still drove it through the classic `httpx`-based client. Migrate to the httpx2 transport and drop the constraint: - Dev dependency `httpx>=0.28` -> `httpx2>=2.0`; server-test response annotations `httpx.Response` -> `httpx2.Response` (tests/test_server.py). The TestClient surface is otherwise identical (httpx2 is Pydantic's fork of httpx), so the assertions are unchanged. - Security floors (the load-bearing rationale): all five GHSAs are fixed only on the Starlette 1.x line, with no 0.x backports, so `starlette>=1.3.1` is declared directly in the `[server]` extra as a fail-loud floor — an app pinning a vulnerable 0.x Starlette now gets a resolver error instead of a silently vulnerable server. The `fastapi` floor rises 0.118 -> 0.133 in both the `test` group and `[server]`: 0.133 is the first release to drop FastAPI's own `starlette<1.0.0` cap (0.132 still pins it), i.e. the lowest fastapi that can coexist with the patched line. It subsumes the earlier 0.118 multipart-coercion floor (kept as recorded history; today's lower-bounds lane resolves 0.133 and can no longer re-verify it). - Remove the two now-obsolete `filterwarnings` ignores (the httpx-transport and `app=` shortcut deprecations no longer fire under httpx2; `["error", ...]` proves it — the suite stays green with them gone). - Re-resolve the lock: Starlette 0.52.1 -> 1.3.1, httpx dropped, httpx2 2.5.0, httpcore2 2.5.0 and truststore added (httpx2's trust-store chain replaces certifi), fastapi stays 0.136.3. Docs/config kept consistent: the advisory in docs/compatibility-advisories.md moves to "Resolved" (dated); the stale `starlette<1.0` example references in CONTRIBUTING.md and .github/dependabot.yml are updated. Gates: ruff clean, pyright strict 0 errors, pytest 1722 passed at 100% line+branch coverage (py3.13), and the lower-bounds floor stack (fastapi 0.133.0 + starlette 1.3.1 + httpx2 2.0.0, py3.10) passes the full suite.
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
starlette.testclientnow prefershttpx2when installed, falling back tohttpx. The fallback emits aStarletteDeprecationWarningurging migration; if neither is installed, the existingRuntimeErroris raised pointing athttpx2.Non-breaking: users with only
httpxinstalled keep working, just warned.StarletteDeprecationWarning(UserWarning)tostarlette/exceptions.py(from UseStarletteDeprecationWarninginstead ofDeprecationWarning#3119) - inherits fromUserWarningso it's visible by default.TYPE_CHECKINGguard keeps mypy typing againsthttpx(httpx2 has no stubs yet).AI Disclaimer
This PR was developed with the assistance of either Claude or Codex. I've reviewed and verified the changes.