Re: Hello from Mozilla

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