Support for reading http status code of WebTransport connect requests

[petrroll]

Recent #713 and #263 added amazing support for setting headers for the connect request and also reading the response headers.

Regrettably, reading http status code (which can be set and in case of success is used for connect) hasn't also been added. This is especially problematic for l7 proxies which tend to just deny the request if throttling user (limits, ddos protection ...) and tend to do so without adding any specific headers - relying on 429 status code & identification that the responder was proxy. \

right now it's not really a problem (for us) as none of our proxies support WT anyway (😅) but it is a known problem of websocket and the issue (when support for wt is better) will be analogous.

[petrroll]

cc @wilaw / @jan-ivar

[wilaw]

Both WebSocket and WebTransport JS APIs hide the handshake status for the same reason: no CORS-style opt-in exists for WebSocket/WebTransport responses, so exposing arbitrary status codes cross-origin would let any page use them as a scanner — hitting internal endpoints and reading back status/error info the server never agreed to share. So the spec just collapses every handshake failure into one generic signal.

For WebTransport specifically: on failure, ready never resolves and closed rejects with a WebTransportError, which only exposes source ("session" or "stream") and streamErrorCode (0–255, or null). No HTTP status field exists. A 429 just looks like any other rejected promise.

A proxy could conceivably see the status code (since its not running a JS API) , and can fail the client as the original server would have.

[petrroll]

But isn't the disclosure reason effectively equivalent for recently merged response headers? I get that less things set those so there's less information leaked but at the end of the day it's conceptually similar - no?

Also, wouldn't it be possible and arguably very much worth it to add cors style opt-in for these apis?

[jan-ivar]

But isn't the disclosure reason effectively equivalent for recently merged response headers?

No, since response headers are only exposed upon a successful extended CONNECT session, at which point the server is known to support WebTransport.

Also, wouldn't it be possible and arguably very much worth it to add cors style opt-in for these apis?

This was heavily discussed in #637 #264 #489 so unless there is new information that ship has probably sailed.

[petrroll]

Ah, I should learn how to read better. Completely missed that in the spec.

In any case, any chance adding pre-flight could be discussed which would open doors to this?

[jan-ivar]

Reopening #637 would require new information not already covered.

[petrroll]

If I understand that issue correctly (even looking at the linked meeting notes), that decision was solely about whether the current state of WT needs pre-rlight. I understand the answer was no.

It wasn't about whether pre-flight could be added if an additional feature (s.a. returning status code + response headers in case of failure) was desired. Which is what my question here is about.

As for new evidence to support need for such feature... I don't have any new technical reason (I think everything has been said over and over) but i can provide new testimonial why this feature would be extremely useful for (some) big platforms. I.e. the ask isn't theoretical / might be used, the ask if if it comes hundreds of millions users will be guaranteed immediately.

(I understand that by itself isn't anywhere close good enough reason, just saying that that is what I can provide)

[jan-ivar]

CORS preflight is a compatibility patch for legacy HTTP endpoints—a threat WebTransport’s explicit handshake does not share. Requiring preflight is not a positive sign for any new feature.

Fetch is moving toward hiding cross-origin error detail, not exposing more of it.

[petrroll]

I get that, but from developer's POW there's no good solution for handling any persistent non-http connection with auth and possible proxies in between L7 on server side or in client network without complex and perf-costing workarounds. And thus also no way to align web platform with native platforms.

Without error code / headers there's no generic way a proxy can signify error & what kind of error.
And so you need workarounds s.a. within process pre/post flight. Detecting overload (429, ...) is complicated, detecting e.g. challenges for auth errors is impossible (no way to communicate challanges) so you can hardly actually use auth via headers (so you're back at doing all sorts of workarounds known from wss world).

Maybe if there was some "app level" standard of accept wt, send close packet packet (in wss close detail + reason, in wt (not sure, possibly just standard frame)) with what you'd normally put to statusCode + headers, but for it to be anyhow useful it'd need at least somewhat agreed upon standard.

And by that point, I'm not sure what's the benefit of that vs just allowing at least some forms of errors and reponse headers bubble up.

it's all a bit of a mess that frankly really needs solution IMHO

[vasilvv]

I do wonder if we want to allow something like Access-Control-Expose-Headers for HTTP error cases.

[jan-ivar]

§ 14.3. Protocol Security seems relevant here:

Networking APIs can be commonly used to scan the local network for available hosts, and thus be used for fingerprinting and other forms of attacks. WebTransport follows the WebSocket approach to this problem: the specific connection error is not returned until an endpoint is verified to be a WebTransport endpoint; thus, the Web application cannot distinguish between a non-existing endpoint and the endpoint that is not willing to accept connections from the Web.