Net::HTTP required the whole DNS resolver, which also reads the system DNS configuration at load time, only to match Resolv::IPv4::Regex and Resolv::IPv6::Regex when deciding whether to send SNI. Use the same inlined regexps as the copy vendored in RubyGems, so that the two stay identical.
https://github.com/ruby/net-http/commit/5b42d75812
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
(https://github.com/ruby/net-http/pull/348)
The current implementation has a problem with the following case:
```ruby
print("HTTP/1.1 200 OK\r\n")
print("Content-Length: 5\r\n")
print(" \t\r\n")
print("X-After: value\r\n")
print("\r\n")
print("hello")
```
The `" \t\r\n"` line should be processed as obs-fold in RFC 9112:
https://www.rfc-editor.org/rfc/rfc9112.html#section-5.2
> obs-fold = OWS CRLF RWS
> ; obsolete line folding
>
> A user agent that receives an obs-fold in a response message that
> is not within a "message/http" container MUST replace each received
> obs-fold with one or more SP octets prior to interpreting the field
> value.
But it's processed as the header part end:
Header:
```text
HTTP/1.1 200 OK
Content-Length: 5
```
Body:
```text
X-After: value
hello
```
It must be processed as the following (whitespace only obs-fold is
ignored):
Header:
```text
HTTP/1.1 200 OK
Content-Length: 5
X-After: value
```
Body:
```text
hello
```
https://github.com/ruby/net-http/commit/6e2bc82919
Once chunked is not the final transfer coding, read_body_0 fell through
to Content-Length and framed the body by it, which leaves the client and
the server disagreeing about where the response ends.
See RFC 9112 Section 6.3:
https://www.rfc-editor.org/rfc/rfc9112.html#section-6.3
If a message is received with both a Transfer-Encoding and a
Content-Length header field, the Transfer-Encoding overrides the
Content-Length.
https://github.com/ruby/net-http/commit/9fb5b93b52
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Net::HTTPHeader#chunked? matched the token anywhere in
Transfer-Encoding, so a response carrying `chunked, gzip` was
chunk-framed and the bytes after the terminating chunk were left
unread on the connection.
See RFC 9112 Section 6.3:
https://www.rfc-editor.org/rfc/rfc9112.html#section-6.3
If a Transfer-Encoding header field is present in a response and
the chunked transfer coding is not the final encoding, the message
body length is determined by reading the connection until it is
closed by the server.
https://github.com/ruby/net-http/commit/e70762aaf9
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
(https://github.com/ruby/net-http/pull/324)
`Content-Length` value must have only digits.
See also RFC 9110 Section 8.6:
https://www.rfc-editor.org/rfc/rfc9110.html#section-8.6
Content-Length = 1*DIGIT
The current implementation accepts garbage before/after digits such as
`abc5` and `5abc`.
This rejects these invalid values.
But this accepts same values in one `Content-Length`
Content-Length: 5, 5
and in multiple `Content-Length`es:
Content-Length: 5
Content-Length: 5
This is for the following part in the RFC:
https://www.rfc-editor.org/rfc/rfc9110.html#section-8.6-13
> Likewise, a sender MUST NOT forward a message with a Content-Length
> header field value that does not match the ABNF above, with one
> exception: a recipient of a Content-Length header field value
> consisting of the same decimal value repeated as a comma-separated
> list (e.g, "Content-Length: 42, 42") MAY either reject the message
> as invalid or replace that invalid field value with a single
> instance of the decimal value, since this likely indicates that a
> duplicate was generated or combined by an upstream message
> processor.
https://github.com/ruby/net-http/commit/23e859e92e
A peer that keeps sending 1xx responses keeps the client in the read
loop of transport_request indefinitely, since the per-response header
limit resets for each response. Cap the count at 100, the same value
CPython's http.client uses.
https://github.com/ruby/net-http/commit/39cf5f648a
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
https://github.com/ruby/net-http/issues/315https://github.com/ruby/net-http/commit/132c8cc1b1
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Closes https://github.com/ruby/net-http/issues/202
As of June 2026, [RFC 10008][] is a proposed standard.
From the RFC Abstract:
> This specification defines the QUERY method for HTTP. A QUERY requests
> that the request target process the enclosed content in a safe and
> idempotent manner and then respond with the result of that processing.
> This is similar to POST requests, but QUERY requests can be
> automatically repeated or restarted without concern for partial state
> changes.
This commit proposes support for the HTTP Query method by way of the
`Net::HTTP::Query` class along with the corresponding `#query` and
`#request_query` methods.
[RFC 10008]: https://www.rfc-editor.org/rfc/rfc10008.htmlhttps://github.com/ruby/net-http/commit/76b11b3a26
each_response_header read header lines until the blank separator with no
bound on their total size, so a server could exhaust client memory by
sending a large header block. Cap the cumulative size at 1 MiB and raise
Net::HTTPBadResponse once it is exceeded.
https://github.com/ruby/net-http/commit/ebe8f3876f
Co-authored-by: Yusuke Endoh <mame@ruby-lang.org>
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The length limits only ran in initialize_http_header, which responses
bypass: each_response_header builds the response through add_field and
set_field, so an oversized response header field was never bounded. Check
the field value length in set_field and append_field_value, and fold the
key length check into validate_field_name so set_field and
initialize_http_header share one place for validating field names.
https://github.com/ruby/net-http/commit/ab084fdc0c
Co-authored-by: Yusuke Endoh <mame@ruby-lang.org>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The CR/LF check via Regexp#match? requires a String, but the per-part
content type was previously interpolated through to_s and accepted any
object such as a Symbol. Coerce it first to keep that behavior.
https://github.com/ruby/net-http/commit/c07d6581ce
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Field values and the request line are already validated against CR/LF,
but field names were interpolated into the request as-is, allowing
header injection via the key. Validate names in set_field and
initialize_http_header, which cover all paths into @header with a
user-supplied key.
https://github.com/ruby/net-http/commit/4f13ea5047
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This contains various improvements in tests for openssl integration:
- Remove DHE parameters from test servers. OpenSSL is almost always
compiled with ECC support nowadays and will prefer ECDHE over DHE.
- Remove an outdated omission for a bug in OpenSSL 1.1.0h released in
2018. None of our CI systems use this specific OpenSSL version.
- Use top-level return to skip tests if openssl is unavailable.
- Refactor tests for Net::HTTP#verify_callback.
https://github.com/ruby/net-http/commit/35c1745a26
The shutdown process here attempted to terminate the test server
by interrupting it with Thread#kill, and then proceeded to close
the server and join the thread. The kill does indeed interrupt
the accept call, but the close call could also interrupt the
thread as part of notifying blocked threads waiting on that
socket call.
In JRuby, where all of this can happen at the same time, it leads
to the following scenario:
* The server thread enters TCPServer#accept and blocks.
* The main thread calls Thread#kill to interrupt the accept call.
* The server thread wakes up and starts to propagate the kill.
There is a slight delay between this wakeup and removing the
server thread from the TCPServer's blocked threads list.
* The main thread calls TCPServer#close, which sees that the server
thread is still in the blocked list, so it initiates a second
interrupt to raise IOError "closed in another thread" on the
server thread.
* As the kill is bubbling out, another check for interrupts occurs,
causing it to see the new raise interrupt and propagate that
instead of the active kill.
* Because the server is now closed and the rescue here is empty,
the server loop will endlessly attempt and fail to call accept.
I was unable to determine how CRuby avoids this race. There may be
code that prevents an active kill interrupt from triggering
further interrupts.
In order to get these tests running on JRuby, I've made the
following changes:
* Only kill the thread; one interrupt is sufficient to break it
out of the accept call.
* Ensure outside the server loop that the server gets closed. This
happens within the server thread, so triggers no new interrupts.
* Minor cleanup for the pattern of using @ssl_server or @server.
This change avoids the race in JRuby (and possibly other parallel-
threaded implementations) and does not impact the behavior of the
tests.
https://github.com/ruby/net-http/commit/54025b3870
Do not wait Connection Attempt Delay without in progress fds
Reset Connection Attempt Delay when connection fails and there is no other socket connection in progress.
This is intended to resolve an issue that was temporarily worked around in Pull Request #12062.
`TCPServer::new` (used in tests such as `TestNetHTTP_v1_2_chunked#test_timeout_during_non_chunked_streamed_HTTP_session_write`) can only connect over either IPv6 or IPv4, depending on the environment.
Since HEv2 attempts to connect over IPv6 first, environments where IPv6 connections are unavailable return ECONNREFUSED immediately.
In such cases, the client should immediately retry the connection over IPv4.
However, HEv2 includes a specification for a "Connection Attempt Delay," where it waits 250ms after the previous connection attempt before starting the next one.
This delay causes Net::OpenTimeout (100ms) to be exceeded while waiting for the next connection attempt to start.
With this change, when a connection attempt fails, if there are sockets still attempting to connect and there are addresses yet to be tried, the Connection Attempt Delay will be resetted, allowing the next connection attempt to start immediately.
---
Additionally, the following minor fixes have been made:
- The `nfds` value used for select(2) is now reset with each wait.
with a TCPSoerver that is only listening
to avoid AssertionFailedError on Ubuntu.
---
The tests such as
`TestNetHTTP_v1_2_chunked#test_timeout_during_non_chunked_streamed_HTTP_session_write`
expect to raise a `Net::WriteTimeout` due to a failure in writing to the server.
However, on Ubuntu environments,
the server immediately returns a "Connection Refused" in such cases.
The socket created with `TCPSocket.new` that supports HEv2 catches this immediately
and raises a `Net::OpenTimeout`.
As a result, these tests fail due to raising a different exception than expected.
This PR adds `Net::OpenTimeout` asexceptions to avoid these test failures.
