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

From: Brodie Thiesfield <[email-masked]>
Date: Mon, 1 Aug 2011 09:23:55 +0900

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

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 1 Aug 2011 14:53:29 +1000

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 <[email-masked]> wrote:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>