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

Willy Tarreau <> Thu, 21 July 2011 22:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3315211E8079; Thu, 21 Jul 2011 15:30:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.508
X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[AWL=-3.465, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id egTLucTnM75B; Thu, 21 Jul 2011 15:30:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 19D8D11E8075; Thu, 21 Jul 2011 15:29:59 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p6LMTqcZ018232; Fri, 22 Jul 2011 00:29:52 +0200
Date: Fri, 22 Jul 2011 00:29:52 +0200
From: Willy Tarreau <>
To: Dave Cridland <>
Message-ID: <>
References: <> <> <9031.1311082001.631622@puncture> <> <> <> <> <> <> <9031.1311285127.963748@puncture>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9031.1311285127.963748@puncture>
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: Thu, 21 Jul 2011 22:30:01 -0000

Hi Dave,

On Thu, Jul 21, 2011 at 10:52:07PM +0100, Dave Cridland wrote:
> On Thu Jul 21 18:33:38 2011, Willy Tarreau wrote:
> >If someone were to develop a backup/restore solution based on WS,  
> >it would
> >be funny to discover that it cannot be used to restore the DNS  
> >server when
> >this one fails...
> >
> >
> If SRV (with a fallback) is defined as part of the core spec, this  
> usage would use the fallback.

Which would be indicated by which component since the DNS is down ?

> >However in my opinion it could be good to document a recommended DNS
> >architecture for WS, that is judged optimal and the most  
> >interoperable.
> >This could clearly be a separate RFC suggesting how clients and  
> >server
> >can make use of DNS SRV records for HA and LB.
> Okay, a thought experiment for you.
> Let's assume we go ahead with dumb A/AAAA lookups.
> How will it be possible for a server to later inform browser it  
> wishes to use SRV lookups?

The same way it has been stated that browsers should use AAAA records
before A records when they exist. At one point it will be possible to
say "if an SRV record exists, then the browser should preferably use

My point is not that DNS is not useful, just that in *some* cases, it
is all but desirable. Have you ever wondered why every cisco router
on the planet has "no ip-domain-lookups" in its config ? Basically
because core infrastructure component must be able to run with very
low dependencies, and DNS certainly is one dependency that is not
desirable for a number of core infrastructure components. And there
is no reason why those components could not be WS clients.

> If you have an answer for this, we can make it optional, and moreover  
> we can deploy SRV for HTTP as well.

It's not that easy either for HTTP. As I said in an earlier mail, HTTP
(as well as WS) has something special called proxies, which exempt
clients from having to deal with DNS. The simple fact that the server
does not know if the client will be able to use the DNS or rely on a
chain of intermediaries that may use it in various ways is a problem
for making use of DNS extensions mandatory.

You couldn't make DNS SRV mandatory for WS when WS starts with a protocol
upgrade from HTTP which does not mandate use of DNS SRV : the DNS resolving
had to be performed by the HTTP chain well before the connection gets
upgraded to WS. If any existing HTTP component in the chain does not make
use of DNS SRV, everything falls apart.

Experience has shown that a spec is not a way to force the world to change
to accomodate its requirements, rather it's a way to tell the world how to
adopt it at a reasonable cost and effort. The higher the expectations, the
lower the adoption. The most important thing is that the spec is designed
to support smooth upgrades so that real world usage drives it forwards.

Best regards,