Subject: Re: [hybi] extension params (was draft-10 questions)

From: Julian Reschke <[email-masked]>
Date: Sat, 03 Sep 2011 12:56:02 +0200

On 2011-08-01 10:27, Julian Reschke wrote:
> On 2011-08-01 02:23, Brodie Thiesfield wrote:
>> All,
>>
>> During the recent IETF meeting the format of the websocket extension
>> header parameters was brought up. The issue being should the header
>> follow the rules of HTTP (allowing quoted strings) or the simplified
>> rules of websocket draft (allowing only tokens).
>
> Yes. In value parameters.
>
> That's not a strict HTTP rule, but doing so would help reusing existing
> parsers.
>
>> ...
>> Since a websocket connection is plain HTTP prior to upgrade, then a
>> server supporting normal HTTP requests on a connection (i.e. not a WS
>> specific server) will already be using its full HTTP parser.
>>
>> It is not possible to determine what is a WS upgrade message until the
>> headers have already been parsed, e.g. the following message is a
>> valid upgrade but that is not known until the last byte is parsed.
>> Additionally, take away the "Upgrade" header from the end and it is a
>> plain HTTP GET with some unnecessary headers.
>>
>> GET /chat HTTP/1.1
>> Host: server.example.com
>> Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
>> Sec-WebSocket-Origin: http://example.com
>> Sec-WebSocket-Protocol: chat, superchat
>> Sec-WebSocket-Version: 8
>> Connection: Upgrade
>> Upgrade: websocket
>>
>> The WS headers have already been parsed by the HTTP parser. Unless the
>> special parsing of the Sec-Websocket-Extension depends solely on the
>> header key, there can be no special parsing. If it does depend on the
>> header key, then won't this require a change to the HTTP spec to
>> introduce the rule that this header key is parsed specially? If it was
>> so defined, then every header key of every HTTP message will need to
>> be examined to see if it requires the simplified parsing.
>  > ...
>
> It does not depend on the header name; if it did it wouldn't be
> implementable at all.
>
> The concern is just that if we do not allow
>
> Sec-WebSocket-Extensions: bar; baz="2"
>
> in addition to
>
> Sec-WebSocket-Extensions: bar; baz=2
>
> then there's a risk of some implementations re-using parser code,
> accepting the latter form, and some not doing so, creating interop
> problems.
>
> SO far I haven't heard back from Ian (who apparently talked to the other
> Ian), but I think it was mentioned in the session that this does affect
> the API. It does not.
> ...

It would be nice to finally get feedback on this one.

Best regards, Julian

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 7 Sep 2011 16:39:41 +0900

On Sat, Sep 3, 2011 at 19:56, Julian Reschke <[email-masked]> wrote:

> snip

>> It does not depend on the header name; if it did it wouldn't be
Yes. General-purpose HTTP header parser doesn't (cannot) care the grammar of
each header but just pays attention to LWS and quotation not
to falsely recognize CRLF in them as end of message-header.

> snip

Agreed. Developers would want to reuse existing parameter parser (maybe,
ones for Transfer-Coding, etc.) as well as HTTP header parser.

IIRC, at some point when we were discussing what kind of API we should use
for exposing selected extensions, I suggested Ian that we limit the range of
a value of an extension parameter so that it's easier to pass the definition
string to JavaScript (i.e. as DOMString). It was taken in on -07 -> -08
update. The goal was not disallowing quotation. It was fine if the contents
in quoted-string is representable by DOMString..

I don't remember any other reason.

So, as long as the range of characters is limited (e.g. ones in token), I'm
fine with reverting this to allow quoted-string for parameter value.
Different from others, change on extension spec is not so painful as there's
no extension in use practically. I can live with the change.

Thanks,
Takeshi