- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 06 Dec 2010 17:30:20 -0800
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Greg Wilkins <gregw@webtide.com>, hybi HTTP <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
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. Regards, Maciej > > Cheers, > > > On 26/11/2010, at 11:55 PM, Greg Wilkins wrote: > >> The problem with another port, is that the success rate of opening an >> arbitrary port through firewalls is not that high. Thus if >> websocket was allocated it's own sockets, then there would still be >> need for a websocket over 80 protocol (eg like there is BOSH for >> XMPP). > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi
Received on Tuesday, 7 December 2010 01:31:07 UTC