HTTP 101 response NOT for websockets

[yutakahirano]

Currently the spec says:

Any responses whose status is in the range 100 to 199, inclusive, and is not 101, are to be ignored, except for the purposes of setting > timingInfo’s final network-response start time above.

in https://fetch.spec.whatwg.org/#concept-http-network-fetch.

Does anyone know why 101 is excluded? Is it for websockets? If it's for websockets, can we exclude 101 only when request's mode is "websocket"?

[annevk]

What happens in that case? The browser ignores it and waits for a non-1xx response, potentially hanging if none comes?

[yutakahirano]

The browser ignores it and waits for a non-1xx response, potentially hanging if none comes?

Yes. Recently I added tests for 1xx behaviors (https://wpt.fyi/fetch/security/1xx-response.any.html) and wondered if it was possible/reasonable for 101 to have an expectation similar to other 1xx responses.

[annevk]

Cool! I think that would be a reasonable change, especially since you wrote tests.

[annevk]

I thought this was no longer valid, but it still is. It now affects this line:

If status is 101, break.

Another way of handling this might be to refactor "process early hints response" and make it work for any 1xx response, requiring the caller to filter.

Thinking about it, perhaps that's even necessary? Or does a WebSocket handshake succeed if the server first sends a 199 and then a 101? And what about a 199 and then a 103?

cc @bashi @noamr

[annevk]

@noamr @bashi could you please have a look at this?

[noamr]

@noamr @bashi could you please have a look at this?

Will do (this got lost in my inbox)

[noamr]

I thought this was no longer valid, but it still is. It now affects this line:

If status is 101, break.

Another way of handling this might be to refactor "process early hints response" and make it work for any 1xx response, requiring the caller to filter.

I don't see the advantage is that. early hints are specific to 103. Perhaps in the future we would have other provisional 1xx headers that fetch needs to deal with like 101.

Thinking about it, perhaps that's even necessary? Or does a WebSocket handshake succeed if the server first sends a 199 and then a 101? And what about a 199 and then a 103?

Yes, the way I understand a 109 etc. should simply be ignored (until someone specifies that it does something).

[noamr]

Regarding the initial proposal, seems like 101 (apart from the case of WebSocket) is advisory - the client SHOULD upgrade if it things it's advisory. So I think we can change the wording here as proposed.

[annevk]

Yes, the way I understand a 109 etc. should simply be ignored (until someone specifies that it does something).

Okay, so when there's multiple 103s we only acknowledge the first, but if there's a couple of 105s first a subsequent 103 will work fine?

I agree that we could rejigger this when there's another 1xx status that needs special processing.

[noamr]

Yes, the way I understand a 109 etc. should simply be ignored (until someone specifies that it does something).

Okay, so when there's multiple 103s we only acknowledge the first, but if there's a couple of 105s first a subsequent 103 will work fine?

Yes, it's more of an application (HTML) decision specific to 103.

I agree that we could rejigger this when there's another 1xx status that needs special processing.

Great

[bashi]

Sorry missed this too. I agree both of you.

[annevk]

#1491 has a fix.