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 07:10:28 +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: <20101207061028.GM19364@1wt.eu>
On Tue, Dec 07, 2010 at 01:13:28PM +1100, Mark Nottingham wrote:
> 
> On 07/12/2010, at 12:30 PM, Maciej Stachowiak wrote:
> 
> > On Dec 6, 2010, at 4:53 PM, Mark Nottingham wrote:
> > 
> >> I don't think that's the relevant aspect here. "Another port" could be port 80 or port 443 (nasty, and you wouldn't make it the default, but I think you see where I'm going). 
> >> 
> >> The question is why it's necessary to run both HTTP and WebSockets traffic over the *same* port simultaneously -- something that AFAICT is taken as axiomatic, and I'm really wondering why.
> > 
> > Web developers will likely want to operate both a WebSocket service and an HTTP service on the same server, since WebSocket services are likely to be most useful in combination with a Web application that makes use of them. At the same time, they will want their WebSocket traffic to go through firewalls properly. It would be a significant burden if a WebSocket service required a separate domain name, physical or virtual server, and possibly SSL cert.
> > 
> > Thus desire to have a single piece of server software that can dispatch connects to HTTP applications or Web applications as appropriate.
> 
> You don't need a different domain name, hardware, OS instance or certificate to listen to a different port, and if you have a wildcard SSL cert, you can use the same cert for the same port number on two different hosts. 

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.

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.

Regards,
Willy
Received on Tuesday, 7 December 2010 06:11:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:33 GMT