Henrik Nordstrom wrote:
fre 2009-07-17 klockan 16:32 +1200 skrev Amos Jeffries:
3.1.5.1
Connect to the server given by /host/ on port 80 and ask it to
upgrade from HTTP to WebSockets.
The client must send only the following lines:
GET /thepath/ HTTP/1.1
Host: /host/
Upgrade: WebSockets
Connection: Upgrade
terminated by two CRLF as per HTTP specification.
Per HTTP specifications the client SHOULD send more lines, in specific
the User-Agent.
Ah, thanks. Yes there are others that need to be added here for the
formal draft.
3.1.5.2
A server receiving the request SHOULD ignore any other headers
received with the request.
If any data following the headers is received then fail the
WebSocket connection. The server MUST discard any body data
received with an Upgrade request. It MAY respond with a 4xx or
5xx HTTP error code from the HTTP specification.
No, only 4xx. It's the request that is in error for being an WebSockets
Upgrade request, not the server.
I'm thinking 5xx if something went wrong, same as HTTP cases. So that
the WebSockets spec is only limiting the 'good' response, but accepting
of any HTTP error states as also its failure state.
But per HTTP specifications such body data is part of the HTTP Upgrade
request and should be ignored if switching protocols as part of ignoring
the HTTP request which contained the Upgrade request. Consider for
example if the request is a POST request, containing a alternative
simplex representation of the communication meant to be used by a
non-WebSockets server.
Ian: is that a relevant case? you can spec it in or out as needed.
But I'm thinking out, since the idea here is to setup a TCP-link tunnel
then perform authentication handshake inside it. The upgrade request is
only to get the MITM/Surrogates to pass it correctly or fail it cleanly.
3.1.5.4
A server receiving a valid HTTP Upgrade request to WebSockets
and which does not accept that WebSockets upgrade MUST send back
a 4xx or 5xx HTTP response as per section 3.1.5.2.
There is no such requirement in HTTP. Handling Upgrade is purely
optional and the server is free to ignore Upgrade. Upgrade is a "please
upgrade to one of these protocols if supported".
Meaning HTTP does not care what gets returned...
At the non-101 reply point its not usable as a WebSockets link. This
bit is going slightly beyond HTTP in a compatible way and refers to the
WebSockets-enabled server rejecting the socket connection.
Ian mentioned many times WebSockets being 'opt-in'. This clause permits
'opt-in' to be denied by the server. It's irrelevant to non-WebSocket
intermediaries and applies only to WebSocket origin servers. Perhapse
that needs to be worded clearer.
The server SHOULD send only the following lines:
HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
While it's true HTTP does not mandate any headers for 1xx responses,
including things like Server is a good idea in 101 responses, and there
may also be other headers required by the HTTP operation such as
Authentication-Info and possibly other headers as well in future
specifications.
Ah yes. Okay.
Ian: anything else you find useful as required here as well. This is
where you get the "is the mystery server capable of WebSockets" info.
Being the _right_ one needs must separate and handled by the WebSockets
handshake.
Just only specify it at the string level. Specifying the order sent is
fine but confusing because it implies order received. Specifying the
order received beyond 101 is broken.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE6 or 3.0.STABLE16
Current Beta Squid 3.1.0.9
