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

[Julian Reschke <[e-mail]>]

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.

Best regards, Julian