Re: WebSockets negotiation over HTTP

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       mnot_at_yahoo-inc.com