* use Transport.VerifySourceAddress to control the Retry Mechanism
This can be used to rate-limit handshakes originating from unverified
source addresses. Rate-limiting for handshakes can be implemented using
the GetConfigForClient callback on the Config.
* pass the remote address to Transport.VerifySourceAddress
For some requests, the client is required to check the server's HTTP/3
SETTINGS. For example, a client is only allowed to send HTTP/3 datagrams
if the server explicitly enabled support.
SETTINGS are sent asynchronously on a control stream (usually the first
unidirectional stream). This means that the SETTINGS might not be
available at the beginning of the connection. This is not expected to be
the common case, since the server can send the SETTINGS in 0.5-RTT data,
but we have to be able to deal with arbitrary delays.
For WebTransport, there are even more SETTINGS values that the client
needs to check. By making CheckSettings a callback on the RoundTripOpt,
this entire validation logic can live at the WebTransport layer.
* add Transport config options to limit the number of handshakes
* fix accounting for failed handshakes
* increase handshake limits, improve documentation
So far, we used Connection.destroy, which destroys a connection without
sending out a CONNECTION_CLOSE frame. This is useful (for example) when
receiving a stateless reset, but it's not what we want when the server
refuses an incoming connection. In this case, we want to send out a
packet with a CONNECTION_CLOSE frame to inform the client that the
connection attempt is being rejected.
There's no need to have a dedicated shutdown method, as the use case
(shutting down an outgoing connection attempt on context cancellation)
can be achieved by using Connection.destroy.
* Add ConnContext to http3.Server
ConnContext can be used to modify the context used by a new http
Request.
* Make linter happy
* Add nil check and integration test
* Add the ServerContextKey check to the ConnContext func
* Update integrationtests/self/http_test.go
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
* Update http3/server.go
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
---------
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
* interrupt the stream when a panick happened
* move the declaration of errPanicked
* check what's read is a prefix of what's written
* check errPanicked
* use MatchError instead of Equal
* use channel to notify the response has been received
* http3: add remote address to request context
Add the remote address of the underlying packet connection to the
HTTP request context. This is useful for applications that need access
to the actual remote address (wrapped in a net.Addr) rather than just
its string representation.
Fixes#4198
* add an integration test to the self test suite.
I was not sure how deep we want to go to assure the right value is set.
For now, it asserts that a net.Addr is present in the context.
Due to the dynamic nature of the requests, it is a bit harder to know
exactly how the remote address will look like. IPv4 vs IPv6, random high
port. I think it is fine to only assert that the value is present.
When resuming a TLS session using Dial (and not DialEarly), 0-RTT should
be disabled at the TLS layer, even if the session ticket allows for
0-RTT resumption.
This bug is not critical, since Dial doesn't return an EarlyConnection,
so the client wouldn't be able to actually send 0-RTT data in practice.
This is more consistent with both the RFC and the rest of the API. For
example, the option in the Config is already name EnableDatagrams, and
the property in the ConnectionState is named SupportsDatagrams.
There is no good reason to manually set the validity period for Retry
tokens. Retry tokens are only valid on a single connection during the
handshake, so it makes sense to limit their validity to the configured
handshake timeout.
