Handshake is not defined in terms of Fetch

[annevk]

This seems like a problem as this makes it impossible to compare to WebSockets and in general assess how various aspects of the handshake integrate with the web platform's network infrastructure.

E.g., one issue here is what the "credentials mode" ends up being which as per #263 (comment) I learned might be "omit", but this does not appear to be defined anywhere. (And I think I would disagree with as "omit" has generally caused web developer pain for no real end user gain.)

[jan-ivar]

E.g., one issue here is what the "credentials mode" ends up being which ... I learned might be "omit", but this does not appear to be defined anywhere.

WebTransport's step 7.2 of initialize WebTransport over HTTP calls directly into "obtaining a connection",¹ bypassing higher level machinery (fetch, Main fetch and HTTP-network fetch). There's no request object² or credentials mode at this level.

The protocol handshake is specified in 7.6: "Establish a WebTransport session with origin and protocols on connection."

This would obviously need rewriting if we want headers or preflights, but as it stands it seems well-defined (I'm guessing "omit" is closest by omission of its machinery). Are there other parts missing?

---

<sub>1. There's some handwaving "if serverCertificateHashes is specified [do this instead]" tacked on here that undoubtedly could be improved
2. There's a dummy request object in the initial synchronous steps, but it's used solely for the report Content Security Policy violations for request, should request be blocked by Content Security Policy? and should be blocked due to a bad port checks.</sub>

[annevk]

I'm talking about the handshake. Because it doesn't use "fetch" it's unclear how it fits into all kinds of policies user agents have, such as HSTS, referrer policy, redirect handling, credentials, etc.

Everything that does a fetch in the web platform needs to go through the fetch primitive so such details are well-defined.

[jan-ivar]

It seems clear it doesn't do any of that (except credentials as called out). It might be unclear whether it should, but then we probably need to be specific.

HSTS

WebTransport is HTTPS only.

referrer policy

There's no navigation so no referrer

redirect handling

#612

credentials

Monkey-patched as mentioned: "if serverCertificateHashes is specified, instead of using the default certificate verification algorithm, consider the certificate valid if it meets the custom certificate requirements and if verifying the certificate hash against serverCertificateHashes returns true. If either condition is not met, let connection be failure."

Everything that does a fetch in the web platform needs to go through the fetch primitive so such details are well-defined.

WebTransport doesn't "fetch". Its session-specific handshake is defined in https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-overview-06#section-4.1-2.2.1. How do you propose we integrate with fetch here?

[annevk]

There's no navigation so no referrer

What? Referrer is for all requests, not just navigations.

How do you propose we integrate with fetch here?

Are you saying it's somehow fundamentally different from the WebSockets handshake? I thought it was very similar.

[vasilvv]

WebTransport was originally supposed to be its own protocol based directly on top of QUIC. The IETF working group decided to base it on top of HTTP, largely since the ability to re-use existing connection pool was deemed sufficiently valuable to add the associated complexity. This is largely the reason why the current integration works the way it does, at the "obtain the connection" level.

WebTransport requests, by their nature, cannot use a lot of HTTP features: caching, content negotiation, etc. Also, due to differing design goals and circumstances, some aspects differ materially from regular HTTP requests (there is no CORS preflight since WebTransport-capable endpoints are assumed to be origin-aware, there is an explicit control over pooling, non-pooled connections can use serverCertificateHashes, redirects and credentials are unsupported, and so on). At some point, I went through common HTTP headers to determine which HTTP features could be potentially useful for WebTransport sessions, and the list was fairly small (Authentication and user-supplied headers are the main ones).

To address your original question, we might want to be more clear about how browsers are expected to fill out HTTP header fields (the answer currently appears to be "only fill out the headers that are explicitly specified", and the only specified header is Origin), but I am not sure fully integrating it with fetch is the right direction, for the reasons I've outlined above.

(It's not clear to me that was the right direction for WebSockets either, but those have more HTTP-like behaviors than WebTransport currently does.)

[annevk]

Can you clarify what an origin-aware endpoint is? (The whole point with CORS is that you cannot assume anything about the server, so your wording makes me suspect.)

It also seems like there's still a lot more overlap with a normal HTTP request-response than there is not. Do all implementations have a completely separate code path for these requests that does everything from scratch?

[KershawChang]

Can you clarify what an origin-aware endpoint is? (The whole point with CORS is that you cannot assume anything about the server, so your wording makes me suspect.)

It also seems like there's still a lot more overlap with a normal HTTP request-response than there is not. Do all implementations have a completely separate code path for these requests that does everything from scratch?

In Firefox, we reuse the existing HTTP request-response pathways to establish WebTransport connections. So, I think our current behavior should align with the Fetch Specification.

[vasilvv]

Can you clarify what an origin-aware endpoint is? (The whole point with CORS is that you cannot assume anything about the server, so your wording makes me suspect.)

Well, it's the same assumption as WebSockets: we don't do preflights or check Access-Control-Allow-Origin, instead, the server is expected (RFC 6455 says "SHOULD") to check Origin server. WebTransport is in a bit of a stronger position here than WebSockets since it doesn't run over HTTP/1, and thus the risk of a server unintentionally processing WebTransport CONNECT as a regular request is lower.

It also seems like there's still a lot more overlap with a normal HTTP request-response than there is not. Do all implementations have a completely separate code path for these requests that does everything from scratch?

Our implementation currently bypasses the regular HTTP stack almost entirely. This will partially change when we implement pooling, but I don't expect the overlap increase by much.

[jan-ivar]

Is a behavior-neutral PR that calls into fetch like websocket does what we're looking for? What might that look like?

[jan-ivar]

Meeting:

• would accept a behavior-neutral PR (not require any behavior currently not required, and not allow any new behavior currently disallowed)
• some concern over accidentally implying new functionality by future changes to fetch.
• guidance from editors of fetch on which integration approach is best is also sought. @annevk thoughts?

[annevk]

I think essentially doing what WebSockets does would be a good starting point.

As an aside, I strongly suspect that Chromium's current architecture is not desirable. I think eventually we want to support custom request headers (just as people have been asking for in WebSockets) and that will require CORS preflights.

Also, now that I've been explained what an origin-aware endpoint is, I can more confidently say that there's no such thing. There's a set of HTTP request semantics that can go across the origin boundary, but if you want to go beyond that you need CORS preflights. (In theory it would be possible to have a CORS preflight opt-out at the TLS layer, but that's really its own discussion and would apply to fetches in general, not just a single feature.)

[vasilvv]

I think eventually we want to support custom request headers (just as people have been asking for in WebSockets) and that will require CORS preflights.

I don't see the need for CORS preflight for WebTransport requests, regardless of whether custom headers are or are not provided.

Also, now that I've been explained what an origin-aware endpoint is, I can more confidently say that there's no such thing.

This appears to be at odds with RFC 6455, which, at least in my reading, places the burden of verifying the origin on the server (Section 10.2).

In theory it would be possible to have a CORS preflight opt-out at the TLS layer, but that's really its own discussion and would apply to fetches in general, not just a single feature.

WebTransport requires explicit negotiation via HTTP settings; by negotiating WebTransport, the server accepts responsibility for processing WebTransport requests correctly, including verifying the origin.