Re: WebSockets negotiation over HTTP

On Wed, 14 Oct 2009, Amos Jeffries wrote:
>
> 4.1.12 prescribes semi-implicitly that HTTP/1.0 and HTTP/1.2 etc are not
> compatible. Maybe thats what you want. *very* minor enhancement would be
> to make that explicitly stated.

I've added a note to this effect.

> 4.1.13 still has a fragility issue in that it assumes the Upgrade: and
> Connection: headers will retain both their specific sending order and be
> the very first headers in the reply. It will work in most situations, but
> proxies which 'correct' the headers order to have Date: first will kill
> WebSockets.

That's intentional; such proxies don't know about Web Sockets (if they
did, they wouldn't be modifying the headers!) and thus clearly can't
really be trusted to route the traffic unmodified.

> 4.1 14 thru 4.1.23 appear to be a very conflated description of parsing
> the headers.
>
> It seems to me that referencing rfc2616 section 4.2 should be sufficient
> for the parse

Unfortunately, HTTP doesn't define how to parse headers. It defines the
semantics of valid headers, but doesn't say, e.g., what headers are
present in the following:

   HTTP/1.1 200 OK
   : Bar
   Foo
   ::::Quux::::

For Web Sockets I would like to have well-defined processing in the face
of any input, even invalid input. I'd also like to not require that the
processing for headers be as complicated as HTTP's (with continuation
lines, multiple headers being merged, etc).

> and do away with 4.1.15 through 4.1.21. Similar to the way 4.1.23
> mentions www-auth "Obtain [header array] in a manner consistent with the
> requirements for handling the headers in HTTP"

That's a big cop-out on my part... and I expect it to be the source of
many bugs. Unfortunately I don't really see how to make this more
explicit without duplicating content from other specs.

> Mandating drop of connections not conforming to correct format of
> headers is implied and some bits are explicitly stated.

What is implied? Any implication is a bug; the intent is for all
behaviour to be explicitly normatively required.

> That can be cleaned up and locked in by the above and adding a clear BNF
> like: (alpha|hyphen) colon space (ascii)* CRLF

Ok, I added a non-normative ABNF in the protocol description in the
introduction.

> The above would also cover handling of LWS cases. Which are currently
> breaking WebSockets. (less important)

Not sure what you mean here.

> As a minor issue, it explicitly specifies reading single bytes. I can
> see people interpreting that as preventing buffering of received data.

As the conformance section says:

# Conformance requirements phrased as algorithms or specific steps may
# be implemented in any manner, so long as the end result is
# equivalent. (In particular, the algorithms defined in this
# specification are intended to be easy to follow, and not intended to
# be performant.)

> > It would be nice if clients were explicitly allowed to send other
> > headers, e.g., Referer or User-Agent, but it's not critical. Also, by
> > its nature this protocol is going to be fragile on non-CONNECTed HTTP
> > connections, but Ian has already acknowledged this.
>
> That is implied by the mention of also adding www-authenticate and not
> prohibiting other headers sent following the WebSockets ones. The
> servers will now cope and discard according to 4.1 of the current draft.

The draft defines exactly what user agents must send. Extensions (like
proprietary headers) are non-conforming. Of course, other specifications
can extend the handshake to add other headers like Referer, if that's
desired. In the case of Referer, of course, it's somewhat rendundant,
since the Origin is included in the request; if the author really wants to
send the exact referer, he can send it in his data stream.

> In conclusion. Hooray! nearly there :)

Thanks for the feedback!

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'