On 22/10/2009, at 10:52 AM, Ian Hickson wrote:
Until the upgrade is complete, you're speaking HTTP and working with
HTTP implementations.
How so? A WebSocket client is always talking Web Socket, even if it
might
also sound like HTTP.
Yes, but to someone examining the traffic -- whether in a debugger or
an intermediary -- it looks, smells and quacks like HTTP. It declares
itself to be HTTP/1.1 by using the HTTP/1.1 protocol identifier in the
request-line. What's the point of doing that -- i.e., why not use
WebSockets/1.0?
Have you verified that implementations (e.g., Apache module API) will
give you byte-level access to what's on the wire in the request, and
byte-level control over what goes out in the response?
On the server side, you don't need wire-level control over what's
coming
in, only over what's going out.
Yes, you do, because section 5.2 specifies headers as whitespace-
sensitive and header-names as case-sensitive.
There's already a WebSocket module for Apache, by the way:
http://code.google.com/p/pywebsocket/
Cool.
Despite all of this, you say:
The simplest method is to use port 80 to get a direct connection
to a
Web Socket server. Port 80 traffic, however, will often be
intercepted by HTTP proxies, which can lead to the connection
failing
to be established.
which I think is misleading; this is far from the simplest way to use
WebSockets, from a deployment perspective.
True. I've tried to reword this to avoid this possible ambiguity.
I see those changes in -50; looks good (and a very elegant change).
Thanks.
This looks an awful lot like a redirect.
There's no redirection involved here. It's just confirming the
opened URL,
as part of the handshake. The TCP connection is not closed (unless the
handshake fails, and then it's not reopened).
I see now that you have the client-side fail a connection where the
URL
doesn't match, but that's really not obvious in 5.1. Please put some
context in there and reinforce that the URL has to be the URL of the
current script, not just any script.
Ok, I've added a note at the end of that section explaining that the
user
agent will fail the connection if the strings don't match what the UA
sent. Please let me know if you'd like anything else clarified; I
don't
really know exactly what should be made clearer.
Did this get into -50? Don't see anything in the diff...
The most effective way of doing this would be to actually define the
new headers' semantics in your draft; Websocket-Location, for example,
is only defined as client-side and server-side behaviours. I know this
is probably intentional, but people will read all sorts of things into
this header (especially since its name is so similar to other HTTP
headers) unless you give some indication of what it means.
--
Mark Nottingham m...@yahoo-inc.com
