Limit read length of a single response line - #325
Merged
Conversation
rhenium
reviewed
Aug 25, 2026
| res | ||
| end | ||
|
|
||
| if defined?(Net::ReadLimitExceeded) |
Member
There was a problem hiding this comment.
Should we (re-)add net-protocol dependency to the gemspec instead?
Member
Author
There was a problem hiding this comment.
Do you mean we specify supported version of net-protocol?
Member
There was a problem hiding this comment.
Yes, the version that will include ruby/net-protocol#67.
My understanding is that it had to be removed from net-http.gemspec in 2022 in commit 79d90c8 because of the conflict with RubyGems' use of stdlib net-http/net-protocol. That may no longer be an issue now that RubyGems vendors them.
Member
Author
There was a problem hiding this comment.
🆗 Thanks for your explanation because I forgot that. I will do that.
The response header cap added by #219 applies only once a complete line has arrived, so a server that never sends a line terminator can still grow the read buffer without bound, as reported in #315. Read the status line, header lines, chunk-size lines and chunk trailers through net-protocol's readuntil(limit:) so they fail with Net::HTTPBadResponse at MAX_RESPONSE_HEADER_LENGTH, and require the net-protocol that provides it. The cumulative header budget stays separate from the per-line limit so that exhausting the total still reports 'response header too large' rather than blaming a line that is not long. #315 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Without it the tests load whatever net/protocol the Ruby ships rather than the net-protocol the gemspec requires, so on Ruby 2.7, where net/protocol is plain stdlib and not a default gem, readuntil has no limit keyword. BUNDLE_WITHOUT moves to the job so that bundle exec does not then demand the sig group install skipped. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
hsbt
force-pushed
the
claude/net-http-issue-315-26907f
branch
from
August 25, 2026 23:04
8c03ca7 to
9ce5c82
Compare
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.
A server that never sends a line terminator can grow the client's read buffer without bound, as reported in #315. The 1 MiB response header cap added by #219 only applies after a complete line has arrived, so it does not help against an unterminated status line, header line, chunk-size line or chunk trailer.
This PR reads all of those lines through the new
limit:option ofNet::BufferedIO#readuntiland fails withNet::HTTPBadResponseonce a single line exceedsMAX_RESPONSE_HEADER_LENGTH. When the loaded net-protocol does not provide the option yet, the previous behavior is kept and the new tests are omitted, so this can be merged ahead of the net-protocol release. The net-protocol side is submitted separately.Fixes #315