- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 7 Dec 2010 13:13:28 +1100
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Greg Wilkins <gregw@webtide.com>, hybi HTTP <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
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. E.g., someone who doesn't want to buy a separate cert can listen to: myhost.example.com:80 <-- http traffic myhost.example.com:443 <-- websockets traffic* Someone writing a more involved application that needs HTTP-over-SSL as well can do: myhost.example.com:80 <-- http traffic myhost.example.com:443 <--- https traffic websockets.example.com:443 <--- websockets traffic ...by either using their existing wildcard cert, or buying a new one (where the cost is approaching zero). The problems you point out are, on the server side, trivial to address and nearly non-issues; all of the current approaches seem like way-overengineered premature optimisation. Since you generally can't count on the same process (or box, or even colo, in many architectures) handling two requests from the same client, there isn't any benefit to having them in the same address space, and as already discussed, it adds significant complexities for server-side implementers. Regards, * If you buy into the argument that the only usable ports on the Internet are 80 and 443. Personally, I think this attitude just encourages an arms race with firewall vendors. > > 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 > -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 7 December 2010 02:14:06 UTC