Subject: Re: [hybi] header for negotiating extensions

From: Salvatore Loreto <[email-masked]>
Date: Sun, 5 Dec 2010 19:56:06 +0200

On 11/8/10 11:52 PM, Julian Reschke wrote:
> On 08.11.2010 22:43, Greg Wilkins wrote:
>> 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.
> +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.
(as individual)

+1 on the John's proposal and also on the reuse of a common HTTP header 
field pattern

/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 12 Dec 2010 22:44:37 +0000

Greg Wilkins wrote:
> On 9 November 2010 08:53, Dave Cridland <[email-masked]> wrote:
> > On Mon Nov  8 21:43:14 2010, Greg Wilkins 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.

I had an idea: Specify a single header, with comma-separated elements,
and forbid the use of multiple headers.

HTTP libraries, intermediaries etc. (including "transparent" ones
which might realistically sit on a WebSocket route) are allowed by
HTTP's spec to fold multiple HTTP headers into a single one, but they
aren't allowed to split one into multiple headers.

The trouble with my idea is what happened with HTTP.  Someone,
somewhere will implement a popular receiver that only matches a
particular string in that header (if they can get away with it), and
there'll be a need to remain compatible with that receiver for some
years while sending additional negotiation tokens for everything else
to see.  In HTTP it was conveniently solved for temporary Microsoft
bugs by sending multiple Connection or multiple Cache-Control headers
in some cases.

For those cases, multiple headers have been useful in the past to
break the compatibility-progress deadlock.

Plenty of header-usage diversity to prevent a receiver like that from
being able to get away with it is another solution.

-- Jamie