Re: [hybi] #1: HTTP Compliance

[Jamie Lokier <[e-mail]>]

Maciej Stachowiak wrote:
> 
> On May 17, 2010, at 2:04 AM, Greg Wilkins wrote:
> 
> > 
> > All,
> > 
> > I know this issues has been somewhat sidetracked by the
> > discussion about TLS.
> > 
> > However, this particular requirements is conditional for only when
> > sharing a port with HTTP, so I think it valuable to continue to
> > try to finalize this requirement.
> 
> I think we need to reframe this requirement so that it makes sense even if we change the handshake to be at the TLS level rather than at the HTTP level. Both the current requirement and the new requirement would make no sense if the handshake was done via TLS.
> 
> > 
> > Currently there is no clear consensus either way, with perhaps
> > a few more voices against compliance is not required.
> > 
> > For firstly, I'd like to encourage all list lurkers to
> > speak up and help sway the debate one way or the other.
> > 
> > Also, in an attempt to move the conversation on, I'd like
> > flip the question around and ask if somebody can clearly
> > state what is the down side of adopting HTTP compliance
> > other than it might force a breaking change in the
> > -76 draft.   Is there some other requirement that can only
> > be achieved by breaking compliance?
> 
> 
> Ian has claimed that the extra bytes after the request help
> WebSocket fail early in the face of unaware proxies, though we do not
> yet have data showing this to be the case. We do know that without
> this, often the handshake will appear to succeed but transmitting
> messages will fail, for the network setups of many users.
> 
> I don't think anyone has indicated a practical problem caused by the extra bytes.

Yes, we have.  It block useful things:

   - Trying multiple WebSocket subprotocols in turn (on the same connection)
   - Trying a HTTP-based protocol if WebSocket is unavailable (ditto)
   - HTTP authentication if the server responds with an authentication request
   - Pipelining WebSocket frames to avoid the negotation RTT delay

Worse, it makes them difficult to add in future, if they are found to be good.

-- Jamie