Re: [hybi] #1: HTTP Compliance

[Jamie Lokier <[e-mail]>]

Roberto Peon wrote:
> 
>    On Tue, Jul 20, 2010 at 11:47 PM, Ian Hickson <[1][e-mail]> wrote:
> 
>    On Wed, 19 May 2010, Jamie Lokier wrote:
>    > >
>    > > If we want to support multiple subprotocols at once, we can do so
>    > > quite easily by just making the subprotocol list be
>    comma-separated.
>    > > Would this be a good idea?
>    >
>    > I think it is a good idea, although there is a risk of low-quality
>    > server but significant implementations matching a literal string,
>    > breaking when other values are added to the comma-separate list, and
>    > therefore making it impossible for clients to actually use the
>    > capability.
> 
>      Yeah, though since that bug would be specific to implementations of
>      particular subprotocols, it would be pretty localised to individual
>      communities. That's probably an acceptable problem.

Fwiw, this has happened before in generic HTTP clients, including some
major browsers, so it wasn't localised to particular communities.  I
guess requiring "Connection: close" to be literally that without
anything else on the line has gone away now :-) But I'm still not sure
if there are HTTP clients/servers in use which would match
",somekeyword," inside a quoted string in a HTTP header where such
things aren't meant to be matched...

>    > But assuming the comma-separated list did catch on, a consequence of
>    > that would be the "below the API" part of WebSocket would have a
>    place
>    > to add its own distinct entries to the comma-separated list, for
>    > recognition by the other side as transport option requests (such as
>    > compression, etc.), safe in the knowledge it wouldn't break
>    negotiation.
>    >
>    > (Separate headers would be much cleaner for that, though).
> 
>      I don't see why we wouldn't just use separate fields for that. No
>      need to overload the subprotocol field.

It cannot use the subprotocol field if the *current* spec gets
significantly deployed, because the client Javascript sets the
subprotocol field, and the server is entitled to expect to get
*exactly* what the client Javascript sets.

That means WebSocket client implementations cannot transparently
append comma-separated keywords to the subprotocol field without
breaking expectations.

I really hope we sort out feature negotation before there's any
significant deployment.

We should also keep in mind that "below the API" isn't always going to
be a clear line.  Some protocol features may be implementable above or
below the Javascript API, according to client capabilities, and some
might be implemented in a WS-aware proxy away from the browser (for
example keepalive modifications when crossing between different
network types).

-- Jamie