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

Iñaki Baz Castillo <ibc@aliax.net> Sun, 24 July 2011 11:26 UTC

Return-Path: <ibc@aliax.net>
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 9C0CE21F85A7; Sun, 24 Jul 2011 04:26:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Level:
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 QeSnwFMyMZQp; Sun, 24 Jul 2011 04:26:55 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id EDA6421F8586; Sun, 24 Jul 2011 04:26:54 -0700 (PDT)
Received: by qwc23 with SMTP id 23so2674153qwc.31 for <multiple recipients>; Sun, 24 Jul 2011 04:26:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.227.136 with SMTP id ja8mr2630820qcb.75.1311506813735; Sun, 24 Jul 2011 04:26:53 -0700 (PDT)
Received: by 10.229.185.195 with HTTP; Sun, 24 Jul 2011 04:26:53 -0700 (PDT)
In-Reply-To: <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> <20110722054345.GE18126@1wt.eu>
Date: Sun, 24 Jul 2011 13:26:53 +0200
Message-ID: <CALiegfnYm6g63JDHLiSH__r-or3kzK0XCVa3cC7RMP14KWBOSg@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: Willy Tarreau <w@1wt.eu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Sun, 24 Jul 2011 11:26:55 -0000

2011/7/22 Willy Tarreau <w@1wt.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.

This is, your text below is valid just in the case I browse a web page
in http://some-domain.org (so port 80) and retrieve a WS URI to
connect to ws://some-domain.org (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. 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.
So sending the GET with "upgrade" has nothing to do with any previous
HTTP communication with the HTTP server.



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



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


Regards.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>