Subject: [hybi] About WebSocket extensions negotiation

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 22 Aug 2011 18:24:16 +0200

The current way of negotiating extensions during WS handshake states
that the client offers some capabilities it implements and the server
decides which ones tu use within the WS connection.
I don't like it too much as the client cannot *require* the usage of a
specific extension but just "ask for it".

I would like to propose a different mechanism as present in SIP
protocol (but adapted to WebSocket):

        GET /chat HTTP/1.1
        Host: server.example.com
        Upgrade: websocket
        Connection: Upgrade
        Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
        Sec-WebSocket-Origin: http://example.com
        Sec-WebSocket-Protocol: chat, superchat
        Sec-WebSocket-Version: 8
        Sec-WebSocket-Supported:  aaa, bbb, ccc
        Sec-WebSocket-Require:  ddd, eee

The server could decide whether to use or not the extensions listed in
Sec-WebSocket-Supported, and MUST accept all the extensions in
Sec-WebSocket-Require.

In case the server does not understand some extension in
Sec-WebSocket-Require, then it MUST reject the handshake with
"HTTP/1.1 420 Bad Extension":

  http://tools.ietf.org/html/rfc3261#section-21.4.15

If all goes OK, the server replies 101 including a
Sec-WebSocket-Require which MUST contain, at least, all the extensions
the client wrote in its Sec-WebSocket-Require. The server can also
include there extensions provided by the client in the
Sec-WebSocket-Supported header (if it implements them and decides to
use them).

Even better, the server could require some extension "zzz". And in
case such extension is not included in the client's
Sec-WebSocket-Supported or Sec-WebSocket-Require headers, then the
server MUST reject the handshake with "HTTP/1.1 421 Extension
Required" (and a header Sec-WebSocket-Require the required
extensions).

  http://tools.ietf.org/html/rfc3261#section-21.4.16

In the other side, if the client puts "aaa" in its
Sec-WebSocket-Require and "aaa" is not present in such a header in the
101 response, or it contains an extension not supported by the client,
then the client MUST close the WS connection.

Yes, too late, I know. Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: John Tamplin <[email-masked]>
Date: Mon, 22 Aug 2011 12:59:53 -0400

> specific extension but just "ask for it".

The client can require it -- when it gets the response back from the server,
if it doesn't include any extensions that it requires, it closes the
connection.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 23 Aug 2011 02:05:45 +0900

> specific extension but just "ask for it".

This enables clients to tell the server "without extension X, I'll
disconnect".

IIUC, clients benefit from this if there's sort of extensions that servers
can serve but are reluctant to accept (wanna reject if possible) because of
resource requirement, etc. Right?

Could you please list extensions that have this characteristics you have in
your mind?

> Required" (and a header Sec-WebSocket-Require the required

Same here.

I understand the nuance but it needs justification for additional
complexity.

BTW, how about required parameter instead? Having two separate list of
extensions complicates how (in which order) to apply them. Now the order of
extensions listed in the Sec-WebSocket-Extensions is significant.

Thanks,
Takeshi

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 23 Aug 2011 02:08:21 +0900

> extensions listed in the Sec-WebSocket-Extensions is significant.

Clarification: required parameter -> "required" parameter

I meant annotating each extension using extension parameter.

---

From: Philipp Serafin <[email-masked]>
Date: Mon, 22 Aug 2011 19:22:05 +0200

> I understand the nuance but it needs justification for additional
This reminds me of some problems with the Accept header for HTTP that, I
believe, Firefox developers had discovered. (If there is demand, I can
try and find the related ticket again.)
Basically they were reluctant to give plugins and extensions the
abillity to add types to the Accept header and instead had set it to a
fixed string. The rationale was, that the Accept header could grow huge
in size if more and more extensions added their own content types there.
If the header became too large, it would significantly add to HTTP
overhead and cause problems with proxies that limit headers to a certain
size.

The overhead would be smaller for WS, since WS handshakes will be done
significantly less frequent than ordinary HTTP requests. But with
respect to proxies, requiring a client to announce ALL available
extensions on every handshake could still eventually become a problem.

An "extension required" code could solve this problem - Clients would
only announce extensions that they want to negiotate or that they
reasoneably expect the server requires. (due to heuristics). If a server
requires an extension that is not listed, it would issue an "extension
required" response and the client would try the handshake again, this
time with the desired extension listed. (Provided the client supports it)

The whole thing boils down to the question if we'll ever have so many
official or proprietary extensions in use that header size could become
a problem.

---

From: John Tamplin <[email-masked]>
Date: Mon, 22 Aug 2011 13:25:40 -0400

On Mon, Aug 22, 2011 at 1:22 PM, Philipp Serafin <[email-masked]> wrote:

> official or proprietary extensions in use that header size could become a
> problem.
>

I don't see any reason we can't address it at the point that occurs, rather
than now.  It would simply be an optimization, and listing all the supported
extensions would still work, so I think if it ever becomes a problem we
could address it then.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 22 Aug 2011 19:54:35 +0200

> if it doesn't include any extensions that it requires, it closes the

The problem is that the server does not know if the client has closed
the connection due to the lack of an extension in the 101 response.
Difficult to debug then.

Or at least, there could be a new WS close status code (i.e 1008
"Extension Required") which is sent by the client to inform the server
that it closes the connection because the server does not include an
extensions asked by the client. It would change nothing in the current
spect, and could be useful.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: John Tamplin <[email-masked]>
Date: Mon, 22 Aug 2011 13:58:30 -0400

> spect, and could be useful.

I would be fine defining a new error code.  However, I think for it to
actually be useful you need to include the required extensions, which means
making the close frame more complicated.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 22 Aug 2011 20:03:25 +0200

> making the close frame more complicated.

I've suggested exactly that in a new mail :)

I've suggested to include the name of the affected extensions within
the descriptive reason/text after the status code.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: John Tamplin <[email-masked]>
Date: Mon, 22 Aug 2011 14:10:13 -0400

> the descriptive reason/text after the status code.

Then I think it is not useful for anything besides logging -- you couldn't
use it for the client to then offer the extension that the server required
(though in the current spec, a client should be advertising everything it
supports anyway).  That isn't to say it isn't useful, but the descriptive
text is just for human consumption and not machine-parseable.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 22 Aug 2011 20:13:44 +0200

> text is just for human consumption and not machine-parseable.

I've explained and justified exactly that in my new thread speaking
just about this new status code :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 22 Aug 2011 20:26:06 +0100

John Tamplin wrote:
>    On Mon, Aug 22, 2011 at 12:24 PM, IÃ±aki Baz Castillo
>    <[1][email-masked]> wrote:
> 
>    The client can require it -- when it gets the response back from the
>    server, if it doesn't include any extensions that it requires, it
>    closes the connection.

If the HTTP negotiation were rejected with an HTTP error, then the
client could reuse the connection with a new request, either trying a
different combination of capabilities, or adding it back to the HTTP
connection pool to immediately reuse for the over-HTTP method that it
probably falls back to.

If WS close-frames allowed the HTTP connection to be reused -- or to
enter a WS renegotiation, that would accomplish the same but seems far
more fragile, potentially insecure, and very unlikely to be approved.

-- Jamie

---

From: Joe Mason <[email-masked]>
Date: Mon, 22 Aug 2011 16:26:29 -0400

The server may not decide to enable all extensions it supports for a connection (for example, under load it may stop accepting requests for extensions that use a lot of resources).  In this case it may want to use the “required” status to make its decision whether to support an extension or not. (“This extension is pretty heavyweight, I’ll only enable it if you REALLY need it.”)

I don’t think that’s important enough to be worth making a change now – just pointing out that the “required” header isn’t totally without utility.

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Tamplin
Sent: Monday, August 22, 2011 1:00 PM
To: Iñaki Baz Castillo
Cc: [email-masked]
Subject: Re: [hybi] About WebSocket extensions negotiation

On Mon, Aug 22, 2011 at 12:24 PM, Iñaki Baz Castillo <[email-masked]<mailto:[email-masked]>> wrote:

The client can require it -- when it gets the response back from the server, if it doesn't include any extensions that it requires, it closes the connection.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.