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

[Brodie Thiesfield <[e-mail]>]

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