Subject: [hybi] WebSocket & HTTP Keep-Alive

From: "Greg Longtin" <[email-masked]>
Date: Sat, 26 Mar 2011 08:35:23 -0500

To all,

Good day.  I don't want to use the term socket, so I'll define a channel as
a unique server ip:port and a client ip:port pair.  With HTTP Keep-Alive,
these channels may stay open after a HTTP request / response, creating a
(short term) group of channels.

The WS specs do not seem to address whether client can use an existing open
HTTP channel to begin a persistent WS connection.  Similarly, once a WS
channel is open, can a client use it for a HTTP request?

>From an abstract perspective, who cares.  From the perspective of server
implementation, it gets interesting in terms of closing Keep-Alive
connections and who listens to what.  Simply put, it complicates things a
bit.

This issue is only a problem when both HTTP and WS are on the same (server)
port.

If I haven't read the specs well enough, please accept my apology.  BTW, in
a past job I dealt with contracts between somewhat unfriendly parties.

Greg Longtin

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 26 Mar 2011 23:47:30 +0100

Hi,

On Sat, Mar 26, 2011 at 08:35:23AM -0500, Greg Longtin wrote:
> HTTP channel to begin a persistent WS connection.

There is nothing which prevents that, because the server switches to
the WS protocol upon a perfectly valid HTTP/1.1 request, and nothing
dictates that this request must be the first one of a connection.

> Similarly, once a WS

No this is not possible, because HTTP offers provisions for upgrading
the HTTP protocol to something else, but there is nothing to do the
opposite. In practice, what will happen is that most components will
switch from HTTP to raw TCP and will not inspect the stream any further,
so most of them will not be able to switch back to HTTP. Thus, even if
we wanted to do that, it would be very dangerous to do so because we
could have large combinations of undesired states between the intermediaries
which are able to switch back and the other ones.

> connections and who listens to what.  Simply put, it complicates things a

On the server side it should not be an issue at all, since every HTTP
requests are independant within a connection, so there should be no
reason why something which can be done in the first request could not
be done in the second or third.

> If I haven't read the specs well enough, please accept my apology.

I don't think so, it's possible that some points on the subject would still
merit some clarifying depending on the audience's experience with various
practices.

Regards,
Willy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 27 Mar 2011 06:44:09 +0200

On Mar 26, 2011, at 11:47 PM, Willy Tarreau wrote:
> opposite.

It is possible if WS defines some way to do it, like Upgrade is
defined for HTTP.  It would require strict framing to prevent
applications from taking control of that feature for MITM attacks.

....Roy

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 27 Mar 2011 08:18:16 +0200

On Sun, Mar 27, 2011 at 06:44:09AM +0200, Roy T. Fielding wrote:
> defined for HTTP.

But HTTP-only intermediaries which will have upgrade and don't
specifically know about WS won't be aware that WS wants to go back
to HTTP, thus they'll remain in their raw TCP mode. This can be quite
dangerous because this could allow the last server to receive HTTP
traffic for a site it isn't, or without the expected intermediary
control, switching or URL filtering.

> It would require strict framing to prevent

Indeed, and I really think that the advantage of being able to switch
back to HTTP after an Upgrade has succeeded is very small, compared to
the issues it opens. However being able to switch to WS on any HTTP
request seems rather important to save a few RTTs (and this one is OK).

Regards,
Willy