Subject: [hybi] header for negotiating extensions

From: John Tamplin <[email-masked]>
Date: Mon, 8 Nov 2010 10:27:58 -0500

Maybe I am just missing it, but I can't find a header in the -03 draft
which is used for negotiating extensions.  Section 8.1 defines the
extension token "deflate-stream", but I don't see anywhere explaining
how this is used.  I propose the following additions to the -03 draft,
which I believe represents what has been discussed here:

- In section 5.1, add a step after #17:

If the client supports one or more WebSocket extensions (such as those
in section 8), it adds "Sec-WebSocket-Extension:", a U+0020 space
character, and a list of extensions defined by the following BNF:

extension-list = extension *( "," extension )
extension = extension-token *( ";" extension-param )
extension-token = registered-token | private-use-token
registered-token = token
private-use-token = "x-" token
extension-param = token [ "=" ( token | quoted-string ) ]

Any extension-token used must either be a registered token
(registration TBD), or have a prefix of "x-" to indicate a private-use
token.  The parameters supplied with any given extension MUST be
defined for that extension.  Note that the client is only offering to
use any advertised extensions, and MUST NOT use them unless the server
accepts the extension.

Non-normative examples of acceptable extension headers:
- Sec-WebSocket-Extension: deflate-stream
- Sec-WebSocket-Extension: mux; max-channels=4; flow-control, deflate-stream
- Sec-WebSocket-Extension: x-private-extension

- In section 5.1, step #44, add an entry:

-> If the entry's name is "sec-websocket-extension":
Parse the value of the field as described by the BNF above into a list
of extension tokens and a possibly empty set of parameters for each.
If any extension token was received which was not advertised by this
client during this handshake, the client MUST fail the connection and
abort these steps.  Otherwise, process the accepted extensions and
their parameters as defined for each extension.  Note that the order
of entries is not significant -- any interaction between multiple
extensions MUST be defined by those extensions (for example,
compressing before multiplexing or after).

- In section 5.2.1, add an entry:

|Sec-WebSocket-Extension|
The value is a list of extensions offered by the client, with a
possibly empty set of parameters for each (see XXX above).

- In section 5.2.2, step #11, add:

|Sec-WebSocket-Extension|
The value is a list of accepted extensions and parameters for each
which the server understands and is willing to use on this connection.
 Extensions not listed by the client MUST NOT be included.  Note that
the parameters do not have to be the same as sent by the client; their
meaning and how the returned value should be calculated is defined by
each extension.

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

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 9 Nov 2010 08:43:14 +1100

John

I'm generally +1 on this proposal.

The only thing I would note is that it might be good to follow HTTP
and allow multiple header lines to be equivalent to a single coma
separated line, so that instead of saying:

  Sec-WebSocket-Extension: x-some-ext; param=value, mux;
max-channels=4; flow-control, deflate-stream

It could be sent as

  Sec-WebSocket-Extension: x-some-ext; param=value
  Sec-WebSocket-Extension: mux; max-channels=4; flow-control
  Sec-WebSocket-Extension: deflate-stream

If we wanted simplicity, then it would be better to specify the multi
line style and avoid having to worry about quoted comas etc.

cheers

On 9 November 2010 02:27, John Tamplin <[email-masked]> wrote:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 08 Nov 2010 22:52:52 +0100

> line style and avoid having to worry about quoted comas etc.

+1 to re-use a common HTTP header field pattern.

However, it also means that the format needs to be equivalent; libraries 
are allowed to and *will* fold this into a single comma-separated line; 
thus I don't see how it changes the escaping issue.

Best regards, Julian

---

From: Dave Cridland <[email-masked]>
Date: Mon, 08 Nov 2010 21:53:34 +0000

> separated line, so that instead of saying:

Two ways of saying the same thing can lead to confusion if the two  
ways of saying the same thing are in fact two equivalent methods of  
providing the same information, especially if the two ways of saying  
the same thing are not always treated as two equivalent methods of  
providing the same information, because the two ways of saying the  
same thing are not the same, and the two ways of saying the same  
thing don't look the same, so the two ways of saying the same thing  
must not mean the same, even if they're equivalent.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: John Tamplin <[email-masked]>
Date: Mon, 8 Nov 2010 16:56:16 -0500

> line style and avoid having to worry about quoted comas etc.

Ok, so change extension-list to the following and make a reference to
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2 :

extension-list = 1#extension

---

From: Joe Mason <[email-masked]>
Date: Mon, 8 Nov 2010 18:20:24 -0500

> thus I don't see how it changes the escaping issue.

Can we just disallow commas in extension tokens and param values?  Then we have no escaping issue: a comma is always a new extension.

It's vital that we either disallow commas or define how to escape them, though.  We don't want to reinvent the cookie spec.

Joe

---------------------------------------------------------------------
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.

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 9 Nov 2010 10:58:03 +1100

On 9 November 2010 08:53, Dave Cridland <[email-masked]> wrote:
> Two ways of saying the same thing can lead to confusion if the two ways of
> saying the same thing are in fact two equivalent methods of providing the
> same information, especially if the two ways of saying the same thing are
> not always treated as two equivalent methods of providing the same
> information, because the two ways of saying the same thing are not the same,
> and the two ways of saying the same thing don't look the same, so the two
> ways of saying the same thing must not mean the same, even if they're
> equivalent.

Dave,

I completely agree that having two ways of doing the same thing is
confusing, and if we could rewind time I'd be a strong advocate in the
HTTP spec process to not support two equivalent syntaxes.

But given that the HTTP spec exists - then I think we had best not
make the same mistake and create a second way of specifying HTTP-like
headers.  There should be one set of rules for HTTP headers, not two.
 If websocket creates a new way of parsing HTTP headers, then that too
will result in confusion and error.

Ie better live with the mistake we know than make a new one.

cheers

---

From: John Tamplin <[email-masked]>
Date: Mon, 8 Nov 2010 19:10:56 -0500

> Can we just disallow commas in extension tokens and param values?  Then we have no escaping issue: a comma is always a new extension.

I think that would require new header field parsing code, rather than
reusing what already exists.

> It's vital that we either disallow commas or define how to escape them, though.  We don't want to reinvent the cookie spec.

As I read RFC2616, commas inside quotes are automatically "escaped" as
they don't divide extensions, so that is already solved.

---

From: John Tamplin <[email-masked]>
Date: Mon, 8 Nov 2010 19:24:13 -0500

A slight revision of how it is placed into the document:

- In section 4.7, add a reference to section 8 to the sentence talking
about negotiating extensions during the handshake

- In sections 5.1, 5.2.1, and 5.2.2, only add minimal discussion of
the header and referencing section 8 for details.

- Renumber the existing section 8 to 8.1, and add section 8
"Extensions".  In the intro to that section, give the details of the
Sec-WebSocket-Extension header (including references to RFC2616
section 4.2) and negotiations.