On 17/10/2009, at 9:09 AM, Ian Hickson wrote:
On Wed, 14 Oct 2009, Mark Nottingham wrote:
Section 5.2 does constrain the bytes the server accepts from the
client,
thereby conflicting with HTTP, but only in some small details. In
particular, it makes HTTP header field-names case-sensitive, and
requires certain arrangements of whitespace in them.
Ian, if you can address these small things in section 5.2 it would
help.
If a WebSocket client is connecting to a WebSocket server, then this
isn't
HTTP, it's just the WebSocket protocol. So whether the fields are
parsed
like HTTP is presumably not a problem.
If an HTTP client is connecting to a WebSocket server, then the
server's
response is going to be garbage (from the HTTP client's perspective)
anyway, much like if an HTTP client were to connect to an SMTP
server. So
how the server parses the fields doesn't really matter.
If a WebSocket client is connecting to a WebSocket server, then the
requirements in this section don't apply to the server.
If an HTTP client is connecting to an HTTP server, then the whole spec
doesn't apply.
Which case is the one you are concerned about? Are my conclusions
above
incorrect?
Until the upgrade is complete, you're speaking HTTP and working with
HTTP implementations. 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?
Overall, I guess I'm just not seeing how running WebSockets on port 80
(i.e., co-existant with a HTTP server) is ever a good idea.
Since a sizeable portion of the Internet is accessed through proxies
(e.g., hotels, universities, corporations, mobile phones, and some
ISPs), and none of the deployed infrastructure will support
WebSockets, deploying in this fashion alone won't be workable on the
open Internet; people using this technique will have to also deploy a
fallback server on a different port. So, why bother, and why force
people to write the code for fallback? What value is there in doing it
this way?
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. It requires the server to
be modified extensively (unless the module API allows direct access to
the bytes on the wire for headers, etc.) and it requires a fallback
server on a separate port to be deployed, in most cases.
The other aspect here is that you're really not using Upgrade in an
appropriate fashion; as mentioned before, its intended use is to
upgrade
*this* TCP connection, not redirect to another one.
There's only one TCP connection established. As far as I can tell,
WebSocket never does a redirect of any kind.
-48 5.1 says:
Send the string "WebSocket-Location" followed by a U+003A COLON (:)
and a U+0020 SPACE, followed by the URL of the Web Socket script,
followed by a CRLF pair (0x0D 0x0A).
For instance:
WebSocket-Location: ws://example.com/demo
NOTE: Do not include the port if it is the default port for Web
Socket protocol connections of the type in question (80 for
unencrypted connections and 443 for encrypted connections).
This looks an awful lot like a redirect. 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.
--
Mark Nottingham [email protected]
