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

From: Brodie Thiesfield <[email-masked]>
Date: Mon, 1 Aug 2011 16:39:24 +0900

On Mon, Aug 1, 2011 at 1:53 PM, Greg Wilkins <[email-masked]> wrote:
> Can't this be an instance of being forgiving in what you parse and
> strict in what you generate?
>
> We should allow ws servers to use existing HTTP parsers and to accept
> quoted strings for any of the header values.

Since we are using HTTP for the upgrade, I think that servers should
follow the HTTP spec and accept the HTTP header syntax. In any case
accepting quoted-string is not an onerous requirement.

> However we could also say that ws clients MUST NOT generate any header
> values that need to be quoted.

It should not cause problems since only strings containing double
quotes need quoting, however I don't see the need to add this
restriction.

Regards,
Brodie

> On 1 August 2011 10:23, Brodie Thiesfield <[email-masked]> 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).
>>
>> On Mon, Aug 1, 2011 at 1:02 AM, Patrick McManus <[email-masked]> wrote:
>>> On Sun, 2011-07-31 at 06:13 -0700, Tobias Oberstein wrote:
>>>> 2.
>>>> In the context of a persistent http connection, what is allowed _before_ the WebSocket handshake
>>>> (that is before client sends GET with upgrade header)?
>>>
>>> prior to the 101 the connection is http. So yes, you can send the
>>> bootstrap http request on a reused http connection. You can do anything
>>> HTTP allows you to do, because the handshake is carried out over HTTP.
>>> That's the point of reusing the infrastructure.
>>
>> 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.
>>
>> If a WS only handshake is ever defined, then all limitations can be
>> decided here, but since the current handshake is using HTTP for
>> bootstrapping, I don't think that we can specify any format for any
>> part of the upgrade message that differs from HTTP.
>>
>> Of course, a server implementation may not implement a full HTTP
>> parser and return a 400 error on quoted string, but for the spec I
>> believe that we are bound by their spec until the protocol has been
>> switched to WS.
>>
>>
>> Regards,
>> Brodie
>> _______________________________________________
>> hybi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 01 Aug 2011 10:27:21 +0200

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

> ...
 > ...

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