search

ietf-wg-webtrans / draft-ietf-webtrans-http3

Internet Drafts for WebTransport
Other
40 stars 13 forks source link

clarify if Extended CONNECT can be sent before receiving the server's SETTINGs frame #139

Closed marten-seemann closed 8 months ago

marten-seemann commented 8 months ago

RFC 9114, section 7.2.4.2 says:

An HTTP implementation MUST NOT send frames or requests that would be invalid based on its current understanding of the peer's settings.

It's not clear if this applies to the WebTransport Extended CONNECT request.

There seems little harm in sending the request immediately, if the server doesn't support WebTransport, it can just reject it.

LPardue commented 8 months ago

The server needs to have advertised SETTINGS_ENABLE_CONNECT_PROTOCOL or else the request with :protocol is an unknown pseudo-header that must be treated as a malformed rquest per https://datatracker.ietf.org/doc/html/rfc9114#section-4.3-3

marten-seemann commented 8 months ago

@LPardue I think you're right. For everyone else wondering which sentence it is:

Endpoints MUST treat a request or response that contains undefined or invalid pseudo-header fields as malformed.

DavidSchinazi commented 8 months ago

That said, since servers MUST treat malformed request as a stream error (as opposed to a connection error), then we don't really have a problem here. If the client sends the request optimistically before it's received settings, then the request will fail - and that's the same outcome as when the settings don't indicate extended connect support. Luckily we have a keyword for such scenarios.

LPardue commented 8 months ago

H2 and H3 allow any server to close the connection if they want. You might be suprised to find that severs that see bad requests might eventually block clients that keep doing this, or that they rip down a conn3ction on the first occasion.

This could ruin the day if the connection is being pooled with non-WebTransport requests

marten-seemann commented 8 months ago

It's fine that the client has to wait for the server's SETTINGS. SETTINGS frames can be sent in 0.5-RTT data, so (in the common case) this doesn't cause any additional latency.

The important part is that SETTINGS_ENABLE_CONNECT_PROTOCOL is only sent by the server, not by the client. This means that the server doesn't need wait for the client's SETTINGS.

vasilvv commented 8 months ago

I think this is the same as #135

I think both the client and the server have to wait for settings, otherwise things don't work.

DavidSchinazi commented 8 months ago

Chair: discussed in the WG session at IETF 118. Consensus in the room was to have client wait for the server's SETTINGS before sending the WebTransport request. I've opened up #143 to discuss how the server should handle receiving the request before settings. I'm closing this issue, we can continue the discussion in either #135 or #143.