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

Willy Tarreau <w@1wt.eu> Fri, 22 July 2011 05:43 UTC

Return-Path: <w@1wt.eu>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B1221F869E; Thu, 21 Jul 2011 22:43:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.279
X-Spam-Level:
X-Spam-Status: No, score=-5.279 tagged_above=-999 required=5 tests=[AWL=-3.536, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jS9WjeMI4+2d; Thu, 21 Jul 2011 22:43:58 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 3706721F866A; Thu, 21 Jul 2011 22:43:57 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p6M5hjQ1019378; Fri, 22 Jul 2011 07:43:45 +0200
Date: Fri, 22 Jul 2011 07:43:45 +0200
From: Willy Tarreau <w@1wt.eu>
To: =?iso-8859-1?Q?I=F1aki?= Baz Castillo <ibc@aliax.net>
Message-ID: <20110722054345.GE18126@1wt.eu>
References: <CALiegfk_GLAhAf=yEe6hYw2bwtxEwg9aJN+f0Bm9he5QgsRavA@mail.gmail.com> <CAP992=Ft6NwG+rbcuWUP0npwVNHY_znHmXmznBQO_krMo3RT6g@mail.gmail.com> <CALiegfmTWMP3GhS1-k2aoHHXkUkB+eWqV=2+BufuWVR1s2Z-EA@mail.gmail.com> <20110721163910.GA16854@1wt.eu> <CAP992=FrX5VxP2o0JLNoJs8nXXba7wbZ6RN9wBUYC0ZSN_wbAg@mail.gmail.com> <9031.1311270000.588511@puncture> <CALiegf=pYzybvc7WB2QfPg6FKrhLxgzHuP-DpuuMfZYJV6Z7FQ@mail.gmail.com> <CAP992=FJymFPKcPVWrF-LkcEtNUz=Kt9L_ex+kLtjiGjL1T46w@mail.gmail.com> <4E28A51F.4020704@callenish.com> <CALiegf=4K2oWfmZjGMD7J_jyaDtS3i+Mu7R0Wh75Rr+MrQCjtw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CALiegf=4K2oWfmZjGMD7J_jyaDtS3i+Mu7R0Wh75Rr+MrQCjtw@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
Cc: Server-Initiated HTTP <hybi@ietf.org>, IETF-Discussion <ietf@ietf.org>
Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jul 2011 05:43:59 -0000

On Fri, Jul 22, 2011 at 01:22:15AM +0200, Iñaki Baz Castillo wrote:
> Well, in SIP there are NAPTR records because SIP can work over
> different transports (UDP, TCP, TLS-TCP. SCTP, TLS-SCTP). In case of
> WebSocket, it just defined for TCP so NAPTR records don't make sense.
> 
> So just SRV is required:
> 
> a)  _ws._tcp.DOMAIN.COM    for WS URI
> b)  _wss._tcp.DOMAIN.COM   for WSS URI

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.

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

Regards,
Willy