* try to sniff content-type as long as the data is not written to the client
* only write when body is allowed
* fix tests
* fix tests
* fix header count
* fix lint
* merge from upstream
* merge updates from master
* Update http3/response_writer.go
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
---------
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
Currently the HTTPStreamer is implemented on the http.Request.Body. This
complicates usage, since it's not easily possible to flush the HTTP
header, requiring users to manually flash the header before taking over
the stream.
With this change, the HTTP header is now flushed automatically as soon
as HTTPStream is called.
The stream exposes two methods required for doing an HTTP request:
SendRequestHeader and ReadResponse. This can be used by applications
that wish to use the stream for non-HTTP content afterwards. This will
lead to a simplification in the API we need to expose for WebTransport,
and will make it easier to send HTTP Datagrams associated with this
stream.
The stream hijackers only need to be able to associate the stream with
the underlying QUIC connection. They are not supposed to call any
functions on the quic.Connection. As such, the better API is to just
pass them a unique identifier.
The http.Request.Body can be type-asserted to a http3.Settingser. The
Settings method on this interface blocks until the client's SETTINGS
frame has been received.
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.
If the user provides a quic.Config, we shouldn't modify it. Instead, we
should return an error if the user enables HTTP Datagrams but fails to
enable datagrams on the QUIC layer.
* Fix protocol
The default value should be "HTTP/3.0".
* Reject normal request with :protocol header
The :protocol pseudo header is only defined for
Extended Connect requests (RFC 9220).
* save one branch check
* Fix review issue
