- From: Greg Wilkins <gregw@webtide.com>
- Date: Wed, 1 Dec 2010 19:47:46 +0100
- To: John Tamplin <jat@google.com>
- Cc: Adam Barth <ietf@adambarth.com>, "William A. Rowe Jr." <wrowe@rowe-clan.net>, "Roy T. Fielding" <fielding@gbiv.com>, Hybi HTTP <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
If 6543 is the websocket port, then it would not matter in an intermediary intercepted and interpreted CONNECT some.host.com:6543 HTTP/1.1 as the implementation of that is likely to be exactly the semantics that we want. An intermediary that incepts and interpets CONNECT some.special.token HTTP/1.1 is going to break. On 1 December 2010 19:33, John Tamplin <jat@google.com> wrote: > On Wed, Dec 1, 2010 at 1:27 PM, Greg Wilkins <gregw@webtide.com> wrote: >> >> On 1 December 2010 19:01, Adam Barth <ietf@adambarth.com> wrote: >> > That seems like a matter of perspective. When opening a connection to >> > a WebSocket server, can one not view the server as a proxy sever? >> >> >> If Websocket was allocated it's own dedicated port (say 6543 for example), >> then opening a connection to some.host.com:80 and sending >> >> CONNECT some.host.com:6543 HTTP/1.1 >> >> would definitely be like a proxy server (and it could even be >> implemented that way, although I expect many servers would optimise >> out the trombone). >> >> >> But I'm not sure that >> >> CONNECT some.special.token HTTP/1.1 >> >> could be consider a proxy or in the spirit of the HTTP spec. > > I think the concerns about how this interpreted should only be about > intermediaries -- the endpoints know that the connection could be a > WebSocket connection and can process it accordingly. However, the > intermediaries cannot be relied on to recognize this, so the question > becomes which method of sending the WebSocket connection through HTTP > intermediaries is least likely to confuse them and most likely to transit > unharmed? > -- > John A. Tamplin > Software Engineer (GWT), Google >
Received on Wednesday, 1 December 2010 18:48:19 UTC