Subject: Issue with draft-ietf-httpbis-h2-websockets-07 (in RFC Editor queue)

From: Julian Reschke <[email-masked]>
Date: Thu, 9 Aug 2018 07:16:34 +0200

<https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-07#section-4>:

>    o  A new pseudo-header field :protocol MAY be included on request
>       HEADERS indicating the desired protocol to be spoken on the tunnel
>       created by CONNECT.  The pseudo-header field is single valued and
>       contains a value from the HTTP Upgrade Token Registry located at
>       https://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-
>       tokens.xhtml

And in 
<https://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xhtml>:

> WebSocket 	The Web Socket Protocol 		[RFC6455]

But, later on in 
<https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-07#section-5> 
and subsequent examples:

>    The :protocol pseudo-header field MUST be included in the CONNECT
>    request and it MUST have a value of "websocket" to initiate a
>    WebSocket connection on an HTTP/2 stream.  Other HTTP request and
>    response header fields, such as those for manipulating cookies, may
>    be included in the HEADERS with the CONNECT method as usual.  This
>    request replaces the GET-based request in [RFC6455] and is used to
>    process the WebSockets opening handshake.

Note that the registered upgrade token is "WebSocket", but the spec 
requires the use of "websocket".

See also <https://github.com/httpwg/http-core/issues/8>.

Recommendation, in order of preference:

1) Fix the spec to use "WebSocket" consistently.

2) Register "websocket" as alias.

It would probably be good to also clarify that value matching for 
":protocol" is consistent with "Upgrade" in HTTP/1.1, meaning 
case-sensitive.

Best regards, Julian

---

From: Patrick McManus <[email-masked]>
Date: Thu, 09 Aug 2018 21:31:36 +0000 (UTC)

6455 also uses lower case "websocket" when sending (and it mandates case
insensitive parsing when receiving) even though the registry apparently has
"Websocket" defined.

I'd prefer to just register websocket as an alias. in my experience that's
the normal usage.

On Thu, Aug 9, 2018 at 1:16 AM, Julian Reschke <[email-masked]>
wrote:

> <https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-07#section-4
> >:
>
> And in <https://www.iana.org/assignments/http-upgrade-tokens/http-
> upgrade-tokens.xhtml>:
>
> But, later on in <https://tools.ietf.org/html/d
> raft-ietf-httpbis-h2-websockets-07#section-5> and subsequent examples:
>

---

From: Mike Bishop <[email-masked]>
Date: Thu, 9 Aug 2018 23:25:38 +0000

Ick.  This looks like a 6455 erratum – the registration is “WebSocket” but all the (non-normative) examples are “websocket”.  Case-insensitive matching is explicitly permitted, and RFC2616/2817 don’t clearly say that Upgrade tokens are or aren’t case-sensitive that I can find.  (Nor do I see it in 7230…?)

I agree that the direct fix is to register both.

From: Patrick McManus <[email-masked]>
Sent: Thursday, August 9, 2018 2:32 PM
To: Julian Reschke <[email-masked]>
Cc: HTTP Working Group <[email-masked]>; Alexey Melnikov <[email-masked]>; Patrick McManus <[email-masked]>
Subject: Re: Issue with draft-ietf-httpbis-h2-websockets-07 (in RFC Editor queue)

6455 also uses lower case "websocket" when sending (and it mandates case insensitive parsing when receiving) even though the registry apparently has "Websocket" defined.

I'd prefer to just register websocket as an alias. in my experience that's the normal usage.

On Thu, Aug 9, 2018 at 1:16 AM, Julian Reschke <[email-masked]<mailto:[email-masked]>> wrote:

And in <https://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xhtml>:
WebSocket       The Web Socket Protocol                 [RFC6455]

But, later on in <https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-07#section-5> and subsequent examples:

Note that the registered upgrade token is "WebSocket", but the spec requires the use of "websocket".

It would probably be good to also clarify that value matching for ":protocol" is consistent with "Upgrade" in HTTP/1.1, meaning case-sensitive.

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 10 Aug 2018 15:48:35 +1200

On 10/08/18 11:25, Mike Bishop wrote:
> Ick.  This looks like a 6455 erratum – the registration is “WebSocket”
> but all the (non-normative) examples are “websocket”.  Case-insensitive
> matching is explicitly permitted, and RFC2616/2817 don’t clearly say
> that Upgrade tokens are or aren’t case-sensitive that I can find.  (Nor
> do I see it in 7230…?)
> 

I was of the understanding that Upgrade labels are governed by the
relevant protocols equivalent of RFC 7230 section 2.6 rules. So for
example HTTP labels *are* case sensitive, but WebSockets is free to
define sensitivity for its own label.

RFC 6455 defines with a MUST requirement that client send "websocket"
(lower case) in Upgrade headers. Also there is a MUST requiring
case-insensitive match for non-"websocket" to fail the connection
(implying case-sensitive "websocket" is valid).

The situation seems reasonably clear to me that WebSockets Upgrade
values are case-insensitive.

Amos

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 10 Aug 2018 16:28:26 +1200

> (implying case-sensitive "websocket" is valid).

I mean "case-insensitive" ^^ here.

Amos

---

From: Julian Reschke <[email-masked]>
Date: Fri, 10 Aug 2018 07:03:22 +0200

On 2018-08-10 01:25, Mike Bishop wrote:
> ...

<https://github.com/httpwg/http-core/issues/8> and 
<https://www.rfc-editor.org/errata/eid5453>.

 > ...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 10 Aug 2018 07:09:37 +0200

> define sensitivity for its own label.

Is it? What if the code that handles the Upgrade token is 
protocol-agnostic? The problem here is that the IANA registry is 
first-come-first-serve, and also doesn't have a "case-insensitive" flag.

IMHO it would be better to just fix the protocol (ws over h2) - it's not 
even published yet after all.

Best regards, Julian

---

From: Andy Green <[email-masked]>
Date: Fri, 10 Aug 2018 13:23:14 +0800

> even published yet after all.

The problem only exists between RFC6455 talking about case-insensitive 
receive and the registry having one case variation registered - not the 
one all the implementations I know of are using to send, "websockets". 
There're no actual problem in the field... they all send "websockets" 
but would accept case variation on what they receive.  Also registering 
"websockets" will formalize the reality everyone is sending "websockets".

The H2 thing doesn't use the same mechanism, and the CONNECT it does use 
already specifies a single literal

```
5.

The pseudo-header :protocol MUST be included in the CONNECT request and 
it MUST have a value of websocket to initiate a WebSocket connection on 
an HTTP/2 stream.
```

https://tools.ietf.org/id/draft-ietf-httpbis-h2-websockets-03.html

I couldn't see anywhere that the :protocol names are "registered", but 
that's OK isn't it?

When you say, "fix the protocol (ws over h2)" what do you envisage 
getting "fixed" in that?

-Andy

BTW I am curious about implementation status of ws-over-h2 in browsers. 
I know chrome canary has been working for a while with some voodoo to 
enable it, but what about other browsers?

---

From: Julian Reschke <[email-masked]>
Date: Fri, 10 Aug 2018 07:45:59 +0200

On 2018-08-10 07:23, Andy Green wrote:
>> IMHO it would be better to just fix the protocol (ws over h2) - it's 
>> not even published yet after all.
> 

The spec says that the value for ":protocol" is an Upgrade token from 
the IANA registry, hence this mail thread :-)

> When you say, "fix the protocol (ws over h2)" what do you envisage 

That would mean changing "websockets" to "WebSockets".

Best regards, Julian

---

From: Andy Green <[email-masked]>
Date: Fri, 10 Aug 2018 13:55:31 +0800

On 08/10/2018 01:45 PM, Julian Reschke wrote:
>> receive and the registry having one case variation registered - not 
>> the one all the implementations I know of are using to send, 
>> "websockets". There're no actual problem in the field... they all send 
>> "websockets" but would accept case variation on what they receive.  
>> Also registering "websockets" will formalize the reality everyone is 
>> sending "websockets".
>>
>> The H2 thing doesn't use the same mechanism, and the CONNECT it does 
>> use already specifies a single literal
>>
>> ```
>> 5.
>>
>> The pseudo-header :protocol MUST be included in the CONNECT request 
>> and it MUST have a value of websocket to initiate a WebSocket 
>> connection on an HTTP/2 stream.
>> ```
>>

Looks like that was added after the v3 google sent me to

```

4
       A new pseudo-header field :protocol MAY be included on request

https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-07

> That would mean changing "websockets" to "WebSockets".

Or just register "websockets" in the "HTTP Upgrade token registry" and 
job done without changing anything else?

-Andy

---

From: Julian Reschke <[email-masked]>
Date: Fri, 10 Aug 2018 08:14:25 +0200

> job done without changing anything else?

In that case we'd have two tokens in the registry for web sockets, but 
only the lowercased variant would work for ws-over-h2.

Best regards, Julian

---

From: Patrick McManus <[email-masked]>
Date: Fri, 10 Aug 2018 11:12:18 +0000 (UTC)

both specs say to send "websocket" from the registry. We should make the
registry reflect the world rather than trying to do it the other way
around. Its just a registry.

---

From: Felipe Gasper <[email-masked]>
Date: Fri, 10 Aug 2018 08:44:45 -0400

Just to point out: the registry uses the singular, “WebSocket”. I don’t think any major implementations send the plural (regardless of case).

-FG

> On Aug 10, 2018, at 7:12 AM, Patrick McManus <[email-masked]> wrote:
> 
> both specs say to send "websocket" from the registry. We should make the registry reflect the world rather than trying to do it the other way around. Its just a registry.
> 
> 
> 
>> On Fri, Aug 10, 2018 at 2:14 AM, Julian Reschke <[email-masked]> wrote:
>>>>> When you say, "fix the protocol (ws over h2)" what do you envisage getting "fixed" in that?
>>>> 
>>> Or just register "websockets" in the "HTTP Upgrade token registry" and job done without changing anything else?
>>> ...
>> 
>> In that case we'd have two tokens in the registry for web sockets, but only the lowercased variant would work for ws-over-h2.
>> 
>> Best regards, Julian
>> 
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 15 Aug 2018 15:50:38 +1000

As I understand it, implementations are already using this value, so changing the token specified might cause further interoperability issues. 

As such, the pragmatic thing to do seems to be #2 below -- registering "websocket" as an alias (probably with a note explaining why).

Since the registry is FCFS, I don't think we need to get the registration request into *this* document -- but if anyone disagrees, please say so ASAP, as it's in AUTH48.

Cheers,

> On 9 Aug 2018, at 3:16 pm, Julian Reschke <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 15 Aug 2018 10:01:43 +0100

> On 9 Aug 2018, at 22:31, Patrick McManus <[email-masked]> wrote:
> 

Agreed.

>> On Thu, Aug 9, 2018 at 1:16 AM, Julian Reschke <[email-masked]> wrote:

---

From: Julian Reschke <[email-masked]>
Date: Mon, 27 Aug 2018 07:40:45 +0200

> Since the registry is FCFS, I don't think we need to get the registration request into *this* document -- but if anyone disagrees, please say so ASAP, as it's in AUTH48.

I think it would be good to fix the IANA registry before publishing this 
document.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 28 Aug 2018 09:55:24 +1000

Saying that it's an "alias" implies that the values are interchangeable, which seems like an interop issue given the current specs.

IANA and the RFC editor are asking for exact text for the registry values; what should we write?

Cheers,

> On 15 Aug 2018, at 7:01 pm, Alexey Melnikov <[email-masked]> wrote:
> 
>

---

From: Mike Bishop <[email-masked]>
Date: Tue, 28 Aug 2018 20:38:37 +0000

I think it's probably the most interoperable to duplicate the existing entries to the new token. 

-----Original Message-----
From: Mark Nottingham <[email-masked]> 
Sent: Monday, August 27, 2018 4:55 PM
To: Alexey Melnikov <[email-masked]>
Cc: Patrick McManus <[email-masked]>; Julian F. Reschke <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: Issue with draft-ietf-httpbis-h2-websockets-07 (in RFC Editor queue)

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 29 Aug 2018 09:46:38 +1000

> I think it's probably the most interoperable to duplicate the existing entries to the new token. 

That means that it would just say "The Web Socket Protocol" and reference RFC6455. 

I don't think that's helpful; someone looking at the registry would rightly wonder why there are two nearly-identical entries, without any visible means of finding out.

If we're really going to go this route, I'd suggest:

"The Web Sockets Protocol over HTTP/2" with a reference to this specification, along with explanatory text in this spec noting that it's a different value, and why.

Personally, I really wonder if existing implementations have seen enough deployment to preclude just changing the value.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 29 Aug 2018 10:51:30 +1000

Good question.

* RFC6455's title is "The WebSocket Protocol", and that seems to be used _fairly_ consistently in the spec's prose.
* A few places in 6455 refer to it as "WebSockets".
* The WHATWG HTML spec (which appears to be authoritative for the API) has a section title of "Web sockets", and the interface is called "WebSocket", which seems to be used consistently in the rest of the prose. <https://html.spec.whatwg.org/multipage/web-sockets.html#network>
* The URI scheme registry uses "WebSocket". <https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml>
* The HTTP upgrade token registry uses "The Web Socket Protocol" <https://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xhtml>
* RFC7692 uses "WebSocket" very consistently.
* The IANA WebSocket protocol registries seem to use "WebSocket" consistently.

This specification <https://httpwg.org/http-extensions/draft-ietf-httpbis-h2-websockets.html> uses "WebSockets" and "WebSocket" and "The WebSocket Protocol", but uses "websocket" in the actual upgrade.

> On 29 Aug 2018, at 10:33 am, Felipe Gasper <[email-masked]> wrote:
> 
> 
> 
>> On Aug 28, 2018, at 7:46 PM, Mark Nottingham <[email-masked]> wrote:
>> 
> Not to be pedantic, but which of these is the correct name for the protocol?
> 
> 
> a) WebSocket
> 
> b) WebSockets
> 
> c) Web Socket
> 
> d) Web Sockets
> 
> I'm seeing multiple variants in this thread, and while consistency is the topic, I thought it worth asking.
> 
> Thanks!
> 
> - Felipe Gasper
> Mississauga, Ontario
>

---

From: Andy Green <[email-masked]>
Date: Wed, 29 Aug 2018 07:54:46 +0800

> Personally, I really wonder if existing implementations have seen enough deployment to preclude just changing the value.

AFAIK it's not released in normal chrome yet, just canary.

Firefox doesn't have it on by default at least and I didn't get any 
answer trying to find out its status in nightly or whatever here recently.

Libwebsockets has implemented it but no problem accepting old and new 
:protocol names for a while, I guess that's the same situation for 
anyone else that has deployed it on server side.

So changing it now shouldn't be disruptive AFAIK.

-Andy

---

From: Patrick McManus <[email-masked]>
Date: Wed, 29 Aug 2018 17:46:45 +0000 (UTC)

>
> Personally, I really wonder if existing implementations have seen enough
> deployment to preclude just changing the value.
>
>
the 6455 implementations all (to some close approximation of all) use lower
case websocket.. the new protocol is just matching reality. let's not
double down on the registry problem in the new protocol.

---

From: Mike Bishop <[email-masked]>
Date: Wed, 29 Aug 2018 18:27:50 +0000

But existing deployments *of RFC6455* use the lower-case token as well.  If you think we need a separate doc, a very short document saying that the lower-case is also used for the same protocol could be pushed through, I suppose.  But splitting the token for use in h2 versus existing use seems at least as silly, to me.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 30 Aug 2018 10:22:59 +1000

On 30 Aug 2018, at 3:46 am, Patrick McManus <[email-masked]> wrote:
> the 6455 implementations all (to some close approximation of all) use lower case websocket.. the new protocol is just matching reality. let's not double down on the registry problem in the new protocol.

Ah, I forgot about that.

It sounds like we need to:
- register 'websocket' pointing to 6455
- file an errata on 6455 recommending using that for interop, but noting that some might send other casings of the token
- perhaps modify the registry entry for "WebSocket" noting that it's not the preferred protocol artefact / historic / whatever

Alexey?

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 30 Aug 2018 11:09:58 +0100

On Thu, Aug 30, 2018, at 1:22 AM, Mark Nottingham wrote:
> - file an errata on 6455 recommending using that for interop, but noting 
> that some might send other casings of the token
> - perhaps modify the registry entry for "WebSocket" noting that it's not 
> the preferred protocol artefact / historic / whatever
> 
> Alexey?

Sounds like a good plan!