Re: [hybi] #1: HTTP Compliance

[Maciej Stachowiak <[e-mail]>]

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.

If we do get evidence that the extra bytes make the WebSocket protocol work better, and if we do not get evidence that they actually cause a problem for WebSocket servers that are sharing a port with a Web server, then I think we should sacrifice theoretical purity for practical benefit.

That being said, this whole issue is irrelevant if we switch to TLS-only and a handshake based on nextprotoneg (and possibly TLS upgrade followed by nextprotoneg).


We should try to frame the requirements so they do not overly depend on the technical details of the current draft. If a requirement could be completely invalidated by a plausible technical change, then it is framed the wrong way and depends too much on protocol details. It would be an indication that we're trying to move issues that should be technical decisions about the protocol into the requirements document.


Therefore, I think the "HTTP compatible/compliant" requirement should be deleted completely, or rewritten to make sense for any plausible handshake. 


I note that the following requirement would apply reasonably to both the current draft mechanism and the proposed TLS-based handshake (with perhaps added specific mention of HTTPS):

"The WebSocket protocol MUST allow HTTP and WebSocket connections to be served from the same port.  Consideration MUST be given:
         * to provide WebSocket services via modules that plug in to existing web infrastructure.
         * to making it possible and practical to implement standalone implementations of the protocol without requiring a fully conforming HTTP implementation."

and should cover all the practical issues that would actually be faced by servers in either scenario.

Regards
Maciej