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).
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.
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.
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.
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? :)
On 14/10/2009, at 10:07 AM, Robert Collins wrote:
On Wed, 2009-10-14 at 09:59 +1100, Mark Nottingham wrote:
On 13/10/2009, at 10:23 PM, "Ian Hickson" <[email protected]> wrote:
I want to just use port 80, and I want to make it possible for a
suitably
configured HTTP server to pass connections over to WebSocket
servers. It
seems to me that using something that looks like an HTTP Upgrade is
better
than just having a totally unrelated handshake, but I guess maybe we
should just reuse port 80 without doing anything HTTP-like at all.
To be clear, upgrade is appropriate for changing an existing
connection over to a new protocol (ie reusing it). To pass a request
over to a different server, a redirect would be more appropriate (and
is facilitated by the new uri scheme).
Yup; and the major issue here is that websockets *does not want* the
initial handshake to be HTTP. Rather it wants to be something not-
quite
HTTP, specifically reject a number of behaviours and headers that are
legitimate HTTP.
-Rob
--
Mark Nottingham [email protected]
