W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: [hybi] workability (or otherwise) of HTTP upgrade

From: Willy Tarreau <w@1wt.eu>
Date: Tue, 7 Dec 2010 08:29:39 +0100
To: Mark Nottingham <mnot@mnot.net>
Cc: Maciej Stachowiak <mjs@apple.com>, hybi HTTP <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20101207072939.GQ19364@1wt.eu>
On Tue, Dec 07, 2010 at 05:14:02PM +1100, Mark Nottingham wrote:
> On 07/12/2010, at 5:10 PM, Willy Tarreau wrote:
> > In my opinion the problem is not here, but the adoption rate depending
> > on the port. Many organisations implement URL filtering on port 80,
> > white-list based filtering on 443 and nothing else around. If you want
> > to deploy a site which quickly gets a lot of traffic, port 80 clearly
> > is the most suited, which is even more true considering that long polling
> > mechanisms already work over that port.
> Quantify 'many.' According to Adam's paper, ~13% of clients will fail to negotiate with a CONNECT-based solution. Is "many" > 13% of the Internet?

We have no idea where it was measured. If it's in a campus, 13% of failure is
high, considering the general low amount of filtering at those places. If it
was in corporate networks, 13% is low. It also depends on what's the target
for a site which makes use of WS. Individuals are not a problem. Neither are
mobile users because their operator will be able to quickly open a new port.
Schools and corporate networks where admins are responsible for the filtering
definitely are the slower adopters.

> > Also, being able to switch from HTTP to WS over a same socket for some
> > services can save one round trip, but that's marginal in most situations,
> > except from mobile phones.
> Would they negotiate back to HTTP if they need to fetch an image? 

No, once upgraded (whatever the method) we can't reuse the connection to
get back to HTTP.

Received on Tuesday, 7 December 2010 07:30:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:55 UTC