Preserve explicit Content-Length on bodyless server responses - #1352
Open
fredrikekre wants to merge 1 commit into
Open
Preserve explicit Content-Length on bodyless server responses#1352fredrikekre wants to merge 1 commit into
fredrikekre wants to merge 1 commit into
Conversation
A server handler that set a Content-Length header and then completed a HEAD request without writing a body had the header stripped before the response head was sent: the write-mode decision conflated "suppress the body" with "suppress the framing headers". The same stripping applied to 304 responses. Keep suppressing the body, but only remove Content-Length when the status actually forbids it (1xx/204, RFC 9110 section 8.6): a HEAD response should carry the header fields a GET would have produced (section 9.3.2), and a 304 may repeat the Content-Length of the representation it revalidates (section 15.4.5). This fixes the HTTP/1 and live HTTP/2 stream paths, and write_response! (which already handled HEAD via the content_length field but stripped an explicit Content-Length from 304 responses). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1352 +/- ##
==========================================
+ Coverage 88.56% 88.57% +0.01%
==========================================
Files 31 31
Lines 11974 11976 +2
==========================================
+ Hits 10605 10608 +3
+ Misses 1369 1368 -1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
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.
A server handler that set a Content-Length header and then completed a
HEAD request without writing a body had the header stripped before the
response head was sent: the write-mode decision conflated "suppress the
body" with "suppress the framing headers". The same stripping applied
to 304 responses.
Keep suppressing the body, but only remove Content-Length when the
status actually forbids it (1xx/204, RFC 9110 section 8.6): a HEAD
response should carry the header fields a GET would have produced
(section 9.3.2), and a 304 may repeat the Content-Length of the
representation it revalidates (section 15.4.5). This fixes the HTTP/1
and live HTTP/2 stream paths, and write_response! (which already
handled HEAD via the content_length field but stripped an explicit
Content-Length from 304 responses).