WebSocket support

[ricea]

This is related to issue #170, but I wanted to create a separate issue specifically for clarifying the behaviour around WebSockets.

My question is, are "wss" and "https" URLs considered equivalent for Network Error Logging? The Fetch Standard considers "wss" and "https" equivalent for cookies and other purposes (see https://websockets.spec.whatwg.org/#concept-websocket-establish), but it's not clear to me from the NEL standard whether that applies here.

Concretely:

• If a NEL header has been seen on a response to a request to https://example.com:8433/, should that configuration be used for a failed WebSocket connection to wss://example.com:8433/ ?
• Conversely, should a NEL header on a response from wss://example.com:8433/ affect requests to https://example.com:8433/ ?

[clelland]

Until we deal with either #166 or #170, I think the answer here is yes, the spec talks about "network requests" in a way that doesn't take their integration (or lack of) with fetch into account.

And I think that if we do resolve #166 by integrating more tightly with fetch, then WebSocket fetches would still participate in NEL, either by setting the NEL header in their responses, or by generating reports on failure.

So still yes, on both questions.

[clelland]

Is there a specific place in the spec that you think this could be clearer? Happy to patch in some text if you have some.

[ricea]

I think if #166 is resolved in favour of using Fetch, then the issue resolves itself. If not, it might be useful to add some extra words at that point.

[miketaylr]

I'm going to write my understanding of how to specify [=fetch=] handling websockets, and have a few questions along the way. My goal is to be to define NEL via Fetch in a way that websocket connections are handled without anything else special, just like http/s. Maybe some special handling is required, but let's aim for that.

1. Start with calling fetch() w/ request (which has its mode set to websocket).
2. Step 8 of fetch(request) defines fetchParams.
3. Step 15 of fetch(request) calls main fetch with w/ fetchParams.
4. Step 12 of main fetch(fetchParams) switches on fetchParam's request mode, which then returns the result of running scheme fetch w/ fetchParams.
5. Step 3 of scheme fetch(fetchParams) switches on fetchParam's request's current URL's scheme, which returns the result of calling HTTP fetch w/ fetchParams.
6. Step 4.3 of HTTP fetch(fetchParams) sets the response variable to the result of calling HTTP-network-or-cache fetch w/ fetchParams.
7. Step 10.2 of HTTP-network-or-cache fetch(fetchParams) sets forwardResponse (which may end up as the final response to the result of HTTP-network fetch w/ httpFetchParams, includeCredentials, and isNewConnectionFetch.
8. Step 6 of HTTP-network fetch(fetchParams, includeCredentials, forceNewConnection) switches on fetchParams's request's mode (which is still websocket), and calls into obtaining a WebSocket connection w/ fetchParams's request's current URL
9. Once the connection is established, the request happens, the final response is returned (back to step 7, which terminates the request, unless a handful of conditions are met).

I think this mostly works for new WebSocket('https://websocket.example.com/'), but it means if we want to monkey patch HTTP-network fetch we need to make sure we're setting its arguments correctly (maybe not hard?).

However, for new WebSocket('wss://websocket.example.com/'), I think we bottom-out with a Fetch network error (step 4 of scheme fetch), because it doesn't know what a ws or wss scheme is. See https://fetch.spec.whatwg.org/#url.

Does that look right @ricea? Or am I missing something?

[ricea]

https://websockets.spec.whatwg.org/#concept-websocket-establish step 1 converts "ws" and "wss" URLs to "http" and "https", so that's all the Fetch spec ever sees.

The Chromium implementation takes a different approach and only modifies the URL for the bits of code that need it.

[miketaylr]

Mike wrote:

However, for new WebSocket('wss://websocket.example.com/'), I think we bottom-out with a Fetch network error (step 4 of scheme fetch), because it doesn't know what a ws or wss scheme is. See https://fetch.spec.whatwg.org/#url.

@ricea wrote:

https://websockets.spec.whatwg.org/#concept-websocket-establish step 1 converts "ws" and "wss" URLs to "http" and "https", so that's all the Fetch spec ever sees.

I guess my point is that for a ws(s) scheme connection, it never makes it to that point via Fetch because "scheme fetch" step 3 doesn't know about "ws" or "wss" schemes, right?

[miketaylr]

But, if this is the intended state of the world, works for me.

[ricea]

I guess my point is that for a ws(s) scheme connection, it never makes it to that point via Fetch because "scheme fetch" step 3 doesn't know about "ws" or "wss" schemes, right?

I think I don't understand your point. How would you end up with a request with a mode of "websocket" except by going via the WebSocket standard?

[miketaylr]

Oh, I don't know. I'm just learning this stuff. :) Thanks for the answers.