Re: [hybi] #1: HTTP Compliance

[Vladimir Katardjiev <[e-mail]>]

I assume the problem/desire/requirement is to reduce the number of round-trips required for the establishment of a new connection. The "random bytes" are a byproduct of that -- ensure that a WebSocket connection's "open" event is fired when the client knows the connection is actually open, not just when the connection is "maybe" open.

...

Maybe it'd be good to rethink how the entire thing works. So far, the WebSocket handshake itself has been "baked into" whatever previous authentication there is/has been. So... Make a proper WS handshake. It can be asynchronous (a la SPDY), and thus not require an additional RTT. Allow WS data to be sent from the API before open is fired, at the risk of being lost. The current API always risks data being lost anyway, unless some ack protocol is introduced, so this is OK in my view. Fire open after the WS handshake finishes. There's no speed loss for expert programmers who desire the extra ms boost, while the contract of an established WS connection is preserved for amateurs.

Then what's left to define is the protocol switching. In this case, ensure the HTTP upgrade fulfils the requirements on the Upgrade contract in a general way (not just WebSockets). The actual defining is probably not the task of this group, but the requirement most certainly is. It might be something as "simple" as adding a Sec- prefix or something, but just ensure that Upgrade can be used. This paves the way for not just WS using Upgrade, but potentially other protocols as well (as was originally intended).

As for the TLS nextprotoneg, I think making that a requirement for a WebSocket connection always runs on TLS is overkill. If nothing else, it is going to severely delay the number of available implementations until libraries with nextprotoneg appear. Specifically, I wouldn't start implementing a TLS handshake myself, so I'd have to wait for a compliant library. Obviously, I don't like that.

Vladimir

On 17 maj 2010, at 11.04, 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.
> 
> 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?
> 
> 
> regards