feat: follow redirects under the response body cap - #152
Merged
Merged
Conversation
With max_response_body_bytes set and follow_redirects=True, httpware now follows redirects itself, closing intermediate responses unread and capping only the final one, instead of rejecting the combination.
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
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.
max_response_body_bytesandfollow_redirects=Trueused to be refused together (ValueErrorat construction), because httpx2 reads every intermediate redirect body without a limit. With a cap set, httpware now follows redirects itself and caps only the final response.How
client.send(request, stream=True, follow_redirects=False). httpx2 builds the next request (response.next_request), so method rewrites, cookies, body reuse on 307/308 andAuthorizationstripping stay httpx2's.response.history. More thanmax_redirectshops raiseshttpx2.TooManyRedirects, which maps to the sameTransportErroras without a cap.auth=None. Otherwise_build_request_authwould re-apply the client'sauthon every hop, including one to another origin, undoing httpx2's stripping.client.follow_redirectsis read at call time, so a caller-providedhttpx2_clientworks too._terminaluses this only when a cap is set;stream()switches fromclient.stream(...)tobuild_requestplus the same loop when a cap is set. Without a cap nothing changes._terminalpassed the original request to the capped reader, so after a redirectresponse.urland the bodiless-response check (HEAD after a 303) used the wrong request.Trade-offs (cap set and following redirects)
historyhave unread bodies;.contenton them raisesResponseNotRead.DigestAuthruns on the first hop only, so a challenge after a redirect is not answered.Not in this PR
httpx2's
_send_handling_authreads intermediate auth responses (theDigestAuth401) without the cap, with or without redirects. That is a separate bug fix.Behaviour change
Construction no longer raises
ValueErrorfor this combination. Nothing that worked before behaves differently.Verification
just lint-ci,just test(971 passed),just docs-build,just adr-check. Mutations of the history andauth=Nonelines are caught by the new tests in both worlds.