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

Willy Tarreau <w@1wt.eu> Wed, 27 July 2011 10:18 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 C529E21F8B43; Wed, 27 Jul 2011 03:18:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.252
X-Spam-Level:
X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[AWL=-2.509, 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 vuwXgQhv+MpC; Wed, 27 Jul 2011 03:18:06 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id D9F9221F8B36; Wed, 27 Jul 2011 03:18:05 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p6RAHvS1006611; Wed, 27 Jul 2011 12:17:57 +0200
Date: Wed, 27 Jul 2011 12:17:57 +0200
From: Willy Tarreau <w@1wt.eu>
To: =?iso-8859-1?Q?I=F1aki?= Baz Castillo <ibc@aliax.net>
Message-ID: <20110727101757.GA6586@1wt.eu>
References: <CAP992=GedTEfimykCWwdwm=BsZdwFRJO36EO0a_o7iejURJ+tQ@mail.gmail.com> <CALiegfnwNyYDy=SyrqHJXV0ZreADb7F8QySvgdHofW9Hm9miZQ@mail.gmail.com> <CABLsOLCgxDNDs54GUybBzmG8a6rNPzXzFcwf_OU25j5L+AobaQ@mail.gmail.com> <CALiegfnp+kNqnU-_x2ZBZnN8fzP=4+6WO=QPjw1rJzvZmSXEAg@mail.gmail.com> <20110724185949.GB22405@1wt.eu> <9031.1311538720.416128@puncture> <20110724204236.GG22405@1wt.eu> <CALiegfkgukeaiMR-Yc15qUJYCB-KPcoNoX4G6NrN4+DOiDS+tw@mail.gmail.com> <20110726192850.GB3692@1wt.eu> <CALiegfndubt3xgRLFWUikhizsvX60p4+b0DcouX0_m5B8vestg@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: <CALiegfndubt3xgRLFWUikhizsvX60p4+b0DcouX0_m5B8vestg@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: Wed, 27 Jul 2011 10:18:06 -0000

On Wed, Jul 27, 2011 at 11:43:58AM +0200, Iñaki Baz Castillo wrote:
> 2011/7/26 Willy Tarreau <w@1wt.eu>eu>:
> > if you want to have any chance of making SRV *usable* with WS (or
> > HTTP), you have to motivate both sides by showing them that :
> >  - it's better for them to use it than not to use it (both servers and
> >    browsers)
> >  - the additional cost of using it is negligible
> >  - there are no issues with not using it
> 
> These are godd points, but I never wanted to propose SRV for HTTP as I
> consider it's just unfeasible at this time (take into account the
> ammount of HTTP clients in the world, as browsers, libraries in any
> language and so on).

That's where I think you're mistaken. As long as you think of it as mandatory
this will not be possible. When you think of it as optional and with an added
value, then you will progressively see clients adopt it and make use of it.
Since the beginning, you're proposing the option as mandatory "just because"
and not for a perceivable added value by both sides. The downsides then
outweigh the benefits. But maybe the benefits do not really exist after all,
otherwise a valid attractive proposal would already have been made by the
time we spent discussing it.

> >  - leaving the choices to the intermediaries will not cause disruptions
> 
> This last point is hard to accomplish (I'm just talking about SRV for
> WS, not for HTTP) because HTTP proxies should be capable of
> determining that a GET request is in fact a WS handshake, and *just*
> in that case perform SRV procedures over the domain (assuming that
> there won't be SRV in the old, anti-fashion and technologically
> limited HTTP world).

Once again, if you expect *all* HTTP proxies to be able to do that, your
proposal fails. If you expect that at least *some* HTTP proxies will be
able to do that with a benefit, then something is possible. Let me repeat
it, technologies are adopted, not forced on users.

> > I'm pretty sure that can be done, but clearly not the way it's been
> > presented till now.
> 
> If the requeriment for including SRV in WS is also including it in
> HTTP then I surrender. I don't think it will never happen, neither I'm
> an expert in HTTP for such kind of proposal.

Probably that starting by enumerating in a draft the benefits it could bring
would be a good start. You seem to be very well convinced that there are
benefits, so you're probably one of the few persons able to start such a
draft.

Regards,
Willy