Re: [hybi] #1: HTTP Compliance

Willy Tarreau <w@1wt.eu> Thu, 22 July 2010 06:58 UTC

Return-Path: <w@1wt.eu>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 273E63A68A2 for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 23:58:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.818
X-Spam-Level:
X-Spam-Status: No, score=-2.818 tagged_above=-999 required=5 tests=[AWL=-1.375, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_44=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXJ8kMJZHAl7 for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 23:58:40 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 4DE9D3A6834 for <hybi@ietf.org>; Wed, 21 Jul 2010 23:58:40 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6M6wq9g010021; Thu, 22 Jul 2010 08:58:52 +0200
Date: Thu, 22 Jul 2010 08:58:52 +0200
From: Willy Tarreau <w@1wt.eu>
To: Ian Hickson <ian@hixie.ch>
Message-ID: <20100722065852.GN7174@1wt.eu>
References: <068.d07026741c6694cd80652d2a7d34f236@tools.ietf.org> <4BF106AD.6020506@webtide.com> <A42E692A-7210-4FF1-AB4F-CFB3E8C38756@apple.com> <AANLkTinorjXFsTH=TvhhF-+e3Eyen8EA2qL7wFCmqpYe@mail.gmail.com> <Pine.LNX.4.64.1007212247590.7242@ps20323.dreamhostps.com> <20100721230350.GF6475@1wt.eu> <Pine.LNX.4.64.1007220500080.7242@ps20323.dreamhostps.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.64.1007220500080.7242@ps20323.dreamhostps.com>
User-Agent: Mutt/1.4.2.3i
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] #1: HTTP Compliance
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 22 Jul 2010 06:58:43 -0000

On Thu, Jul 22, 2010 at 06:32:02AM +0000, Ian Hickson wrote:
> I see no advantage in the common case to using the same software for both. 
> It's far easier to just host them separately.
> 
> Why don't people use the same software for HTTP and DNS? Or IMAP and SMTP?  
> Or IRC and FTP? Why would they act differently for HTTP and WebSocket?

Ian, you forget one thing : "applications".
HTTP + WebSocket will be combined in the same use to for applications,
with WebSocket being the interactive part, and HTTP carrying all the
transactional parts. For this reason, they will be intimately bound,
there will be a need for shared context, for persistence between the
two protocols from the same user on the same server, for passing
credentials, etc... None of the other examples you've proposed above
need that. And in fact there's one case where IMAP+SMTP are used
together, it's when you require a user to first log into the POP or
IMAP server so that he's allowed to relay through the SMTP server.
And in this case, both are bound ;-)

(...)
> On Thu, 22 Jul 2010, Jamie Lokier wrote:
> > Willy Tarreau wrote:
> > >
> > > [Good description of transparent proxies at ISPs with configurable 
> > > HTTP-aware rules on the routers.]
> 
> What Willy wrote was not a description of transparent proxies but of 
> man-in-the-middle proxies. Transparent proxies are a different beast 
> altogether. Please see the HTTP spec for details. Man-in-the-middle 
> proxies are not legitimate per the HTTP spec as far as I can tell,
> and are the cause of many problems on the Web (such as the lack of
> our ability to deploy pipelining).

Sorry ? what you call man-in-the-middle is what HTTP calls "gateways"
or what are commonly called "reverse-proxies". Not only they don't
cause lots of imaginary problems, they're deployed everywhere and you
don't ever notice them, reason why you believe they don't work. Try
to spot one large site which does not make use of an HTTP gateway in
front of servers. Hint: they're at least in every layer 7 load
balancers. So please stop thinking about your perl-written server
running on your laptop for your own tests and think about the real
world.

> On Thu, 22 Jul 2010, Willy Tarreau wrote:
> > 
> > There are not that many ISPs in each country, I mean there are far less 
> > ISPs than there are web sites or potential WebSocket implementers. 
> > There's a high pressure on them to work as expected by customers.
> 
> Not high enough, clearly, or we'd be able to deploy pipelining.

We'd be able to *enable* pipelining, not deploy it for the other reason
I explained before (high cost and risks on intermediates for little added
value). However, if there are some remaining places where it still does
not work, well it may very well be because it's disabled by default in
browsers so that nobody has to complain.

> On Thu, 22 Jul 2010, Willy Tarreau wrote:
> > > 
> > > (Note: from a conformance standpoint, the "server" includes the 
> > > proxy.)
> > 
> > as seen from the client, yes. As seen from the proxy or the server or 
> > any intermediate between them, no :-)
> 
> I mean as seen from the point of view of conformance to the specification.

Then it's a gateway, not a server.

Willy