Re: [hybi] CONNECT handshake text

[Maciej Stachowiak <[e-mail]>]

On Dec 8, 2010, at 7:42 AM, Ian Fette (イアンフェッティ) wrote:

> 2010/12/8 Simon Pieters <[e-mail]>
> On Tue, 07 
> 
> 
> Fette                     Expires June 8, 2011                 [Page 25]
> %0CInternet-Draft           The WebSocket protocol            December 2010
> 
> 
> 
>   5.  If /secure/ is true, the user agent MUST perform a TLS handshake
>       over the connection.  If this fails (e.g. the server's
>       certificate could not be verified), then the user agent MUST fail
>       the WebSocket connection and abort the connection.  Otherwise,
>       all further communication on this channel MUST run through the
>       encrypted tunnel.  [RFC2246]
> 
>       User agents MUST use the Server Name Indication extension in the
>       TLS handshake.  [RFC4366]
> 
>   Once a connection to the server has been established (including a
>   connection via a proxy or over a TLS-encrypted tunnel), the client
>   MUST send a handshake to the server.  The handshake consists of a
>   CONNECT request, along with a list of required and optional headers.
>   The requirements for this handshake are as follows.
> 
>   1.   The handshake must be a valid HTTP request as specified by
>        [RFC2616].
> 
> The current draft says which bytes should be put on the wire exactly. I prefer the current draft over referencing RFC2616 since doing the latter makes many variations conforming which can cause interop problems.
> 
> 
> And this was a source of contention for many people.

I believe the contention was about restricting handshake parsing to reject the client handshake unless it meets very specific requirements which are tighter than the full syntax for an HTTP request.

I don't think anyone had a serious objection to restricting what the client may send to be a subset of RFC2616-compliant requests.

I believe it is actively harmful to give client implementations an extra degree of freedom here, and there is no particular benefit to the extra flexibility.

In other words, make the generation of the client handshake precise, and let the server parsing be flexible (to the degree that is compatible with security requirements).

Regards,
Maciej