Re: WebSockets negotiation over HTTP

On Wed, 14 Oct 2009 11:58:56 +1100, Mark Nottingham <mnot_at_yahoo-inc.com>
wrote:
> Catching up to Ian's -48 draft*, I don't think there's much of a
> problem here -- or at least the spec can be brought into alignment
> with HTTP with a few small changes. However, the comment about upgrade
> vs. redirect stands (see below).

Thanks for pointing at the number, I was working off an older copy. :(
(sorry Ian).

By the looks of draft 48 HTTP will not break any more when WebSockets
Upgrade is thrown over it. As you point out some small fragility points
remain that may cause WebSockets to false-fail, they will not utterly break
things.

Taking a look at the current draft myself and interleaving (adding to)
Marks comments....

>
> Section 4.1 describes the handshake from the client side. It requires
> the client to send a request that's a subset of HTTP; this doesn't
> conflict with HTTP in and of itself. It also constrains the responses
> to the request that the client can expect, but that's OK because at
> this point we shouldn't be talking HTTP any more.

4.1.1 thru 4.1.10 are workable, modulo the same case-sensitive notion.
Though as you point out being a _sent_ data format it's minor.

4.1.11 thru 4.1.13 are regarding the reply received. There has been much
change to this section that appears to incorporate the points that have
been mentioned over the last few months.

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.

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.

 The detection of these headers could easily be combined with 4.1.23
requiring exactly one copy of each, which solves all these issues.

FYI Squid is not strictly compliant in header handling and merely appends
Date: where missing. This may change.
I have observed one major ISP using proxies advertising themselves 'bcN'
(I would assume that's BlueCoat 1,2,3 etc) which do corrections by
pre-pending headers.

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 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"

  Mandating drop of connections not conforming to correct format of
headers is implied and some bits are explicitly stated. That can be cleaned
up and locked in by the above and adding a clear BNF like: (alpha|hyphen)
colon space (ascii)* CRLF

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

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

>
> 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.

>
> Section 5.1 describes the handshake from the server side. It doesn't
> place any requirements on the bytes received from the client, only on
> those sent by the server, so again this is a proper subset of HTTP.
>
> Section 5.2 does constrain the bytes the server accepts from the
> client, thereby conflicting with HTTP, but only in some small details.
> In particular, it makes HTTP header field-names case-sensitive, and
> requires certain arrangements of whitespace in them.
>
> Ian, if you can address these small things in section 5.2 it would help.

5.1/5.2 seems to have been adapted to take into account our earlier
discussions and now appear to be workable. Thank you Ian.

>
> The other aspect here is that you're really not using Upgrade in an
> appropriate fashion; as mentioned before, its intended use is to
> upgrade *this* TCP connection, not redirect to another one. If you
> really want to just redirect all of the time, you'd be much better off
> doing a normal 3xx redirect to something with a ws: or wss: URL scheme
> -- it would avoid a lot of the fragility we've been concerned about on
> the HTTP side.
>
> Cheers,
>
>
> * Ian, are you just trying to exceed 100 drafts, thereby crashing the
> IETF? :)
>

In conclusion. Hooray! nearly there :)

Amos
Received on Wed Oct 14 2009 - 02:48:54 MDT