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

[Greg Wilkins <[e-mail]>]

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.
However we could also say that ws clients MUST NOT generate any header
values that need to be quoted.

cheers


On 1 August 2011 10:23, Brodie Thiesfield <[e-mail]> 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>