Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard

Willy Tarreau <> Sun, 24 July 2011 12:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8444C21F86C3; Sun, 24 Jul 2011 05:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.753
X-Spam-Status: No, score=-4.753 tagged_above=-999 required=5 tests=[AWL=-3.610, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kcivGLGb3TQj; Sun, 24 Jul 2011 05:08:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7769121F8663; Sun, 24 Jul 2011 05:08:00 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p6OC7pGO026319; Sun, 24 Jul 2011 14:07:51 +0200
Date: Sun, 24 Jul 2011 14:07:51 +0200
From: Willy Tarreau <>
To: =?iso-8859-1?Q?I=F1aki?= Baz Castillo <>
Message-ID: <>
References: <> <> <> <9031.1311270000.588511@puncture> <> <> <> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/
Cc: Server-Initiated HTTP <>, IETF-Discussion <>
Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 24 Jul 2011 12:08:01 -0000

On Sun, Jul 24, 2011 at 01:26:53PM +0200, Iñaki Baz Castillo wrote:
> 2011/7/22 Willy Tarreau <>eu>:
> > Iñaki, what we're saying is that the resolving applies first to HTTP
> > well before it is WS. For instance, a client could connect to an HTTP
> > server, fetch a few objects, then decide to upgrade the connection to
> > switch to WebSocket. DNS resolving for WS would not even be involved
> > here.
> Hi. Maybe I'm the only who assumes that, usually, the WS server is not
> colocated within the initial web server.

Web-based infrastructures make that almost mandatory at the frontend,
especially in massive hosting where you don't want to multiply IP addresses.
In general you have one single point which handles the IP:port and which
dispatches that to many servers based on the Host header, URI, file names,
cookies, etc...

> This is, your text below is valid just in the case I browse a web page
> in (so port 80) and retrieve a WS URI to
> connect to ws:// (so also port 80). In that case you
> say that the http/ws client would decide to upgrade the connection so
> "it must assume that the WS handshake must be sent to the same IP:port
> resolved for the HTTP communication".
> I don't agree with yout point. Doing the "upgrade" does not mean
> reusing an existing TCP connection (in which HTTP took place) for
> other purpose.

Huh ?

> Instead, doing the WS upgrade means opening (or
> reusing) a TCP connection, sending a HTTP GET with special semantics,
> expect 101 and then start a bidirectional frame-based communication.

I still remember how the handshake works, thank you.

> So sending the GET with "upgrade" has nothing to do with any previous
> HTTP communication with the HTTP server.

Yes it has. Either you open a fresh new connection, or you reuse an
idle existing one. But to know that the connection is idle, you must
understand the protocol that was spoken on it and this protocol must
have clearly delimited messages. HTTP supports reuse of connections
(also called "keep-alive") and since the WS handshake is HTTP, it is
possible and I'd add even recommended to reuse an existing connection
to send a WS handshake, if one such connection exists.

> > I agree with what others have been saying : if/when a different handshake
> > is supported, eg. on a specific port without the HTTP upgrade, then it
> > will make sense.
> Do you mean WS as a complete separate protocol running on a specific
> WS port and so? I'd really would like it (rather than the exotic
> pseudo-HTTP mechanism used right now), but I expect it will never
> happen.

I'm sure it will happen. We need applications to be developped using
WS first. But there are places where :
  - HTTP compatibility won't be needed
  - masking will be annoying
  - HTTP overhead will be too much
  - HTTP round trip will be too much

I think that this will happen as soon as a working proposal for TLS NPN
appears, because the same requirements will exist (eg: how to specify
the resource name in a simpler way, etc...). Right now we need WS to be
able to replace long polling mechanisms which already work over HTTP, so
if we want it to be adopted, we need to deploy where previous methods
used to work. You just need to be patient :-)

> > But as of now we're relying on the lower layer. As Greg
> > said it, without a deep change in HTTP you won't be able to make the rule
> > a MUST for WS. However, John's suggest of using a SHOULD when the record
> > exists and the client can see it looks fine. What's the problem if not all
> > of your clients go to the same hosts ? You can even announce all of your
> > servers with A/AAAA and with SRV as well as long as they're running on the
> > same ports. Those who can use SRV just have more information than the other
> > ones and can be served better.
> Having multiple A/AAAA records for a single domain does not provide
> failover (as clients usually take just the first IP). I see your
> point, but I expect no success at all.

That's not what I'm saying. Right now, people are using A/AAAA with short
TTLs and are updating the zones when a site fails (when I mean a site, I
mean a datacenter). This is something which happens rarely enough to be
acceptable. Using fast DNS updates for server failover does not work
because caches are everywhere and experience shows that even after one
month you still receive traffic on a server you've stopped announcing.

However, please read what I've explained in another mail about the
limitations of client-based failover in web environments.