Repository navigation
Fix empty response bodies through the web proxy - #9
Merged
Merged
Conversation
The landing page returned 200 with a zero-byte body in production. fetch transparently decompresses what it receives, but the proxy forwarded the child's content-encoding header unchanged — so the response claimed gzip while carrying plain bytes, and the client decoded it to nothing. The API paths were unaffected because they are served in-process, and /today was a redirect with no body, so only the landing page showed it. The proxy now requests identity encoding from the child and strips content-encoding, content-length and transfer-encoding from the response it returns. Those describe the child's wire format, not this one. CI could not have caught this: plain curl sends no Accept-Encoding, so the child never compressed and the mismatch never arose. The landing check now uses --compressed, like a browser, and asserts a non-empty body. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
The landing page returned 200 with a zero-byte body in production.
Cause
fetchtransparently decompresses what it receives, but the supervisor forwarded the Next child response headers unchanged — includingcontent-encoding: gzip. The response then claimed to be gzipped while carrying plain bytes, so the client decoded it to nothing.Only the landing page showed it: API paths are served in-process and never touch the proxy, and
/todaywas a redirect with no body.The proxy now requests
identityencoding from the child over loopback (compression there buys nothing) and stripscontent-encoding,content-lengthandtransfer-encodingfrom the response it returns — those describe the child wire format, not the one being sent onward.Why CI passed
Plain
curlsends noAccept-Encoding, so the child never compressed and the mismatch never arose. Every browser sends it.The landing check now uses
curl --compressedand asserts a body over 1000 bytes, so a 200-with-no-content fails the build. It also checks/loginhas a body.🤖 Generated with Claude Code