Re: [hybi] #1: HTTP Compliance

On May 17, 2010, at 3:12 AM, Greg Wilkins wrote:

> On 17/05/10 11:29, Maciej Stachowiak wrote:
>> 
>> On May 17, 2010, at 2:04 AM, Greg Wilkins wrote:
>> 
>> 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 understand that is the case for the extra bytes.   But that is not
> what I asked.     The fact that a requirement might be solve with a
> non HTTP compliant mechanism does not mean that it can be solved
> only by non HTTP compliant mechanisms.

True. If someone comes up with a proposal to solve the same problem in a way that doesn't technically violate HTTP, that would be great, and we can consider it. What if there isn't? Do we give up and leave the protocol less effective than it could be for the sake of purity?

I can see how the idea of HTTP compliance should be a preference, but I don't see how it can be a hard requirement, if it turns out that we can make the protocol work better only by violating.

> 
> 
>> I don't think anyone has indicated a practical problem caused by the extra bytes.
> 
> I do not think there is consensus one way or the other on this. So I
> do not think you can yet dismiss the problems raised.

I'm not dismissing problems that may be raised, I just haven't heard any description of how this may break a server. Either a pure HTTP server or a joint HTTP/WebSocket server.

You have raised the notion that it could be a problem if WebSocket clients followed up a refused WebSocket upgrade with HTTP requests, however, the client protocol does not allow this currently, so it is not at this time a practical problem.

Does anyone have an example of how this would cause a practical proble for a server?

> nextprotoneg is not yet widely available or even accepted as a standard, so while
> I agree it is a promising development, unless we are prepared to significantly delay
> websockets then I do not see how we can avoid some port sharing.

TLS + nextprotoneg is a proposal for a specific way to do the port sharing. Tentatively, I think it seems better than the current scheme.

> 
> Note that even with TLS, this requirement is relevant, because without
> nextprotoneg the two ends will not be able to agree that the connection
> is a websocket connection and the connection will have to be HTTP compliant
> over TLS until an upgrade is done.

My understanding is that the connection would fail at the TLS level if the server doesn't support nextprotoneg. 

> 
>> Therefore, I think the "HTTP compatible/compliant" requirement should be deleted 
>> completely, or rewritten to make sense for any plausible handshake.
> 
> I don't see how your arguments to delete the HTTP compliant requirement would not equally
> apply to the requirement below.   The only difference being that it weakens
> the word "compliant" or "compatible" to just "consideration".

I believe the requirement below is still relevant, because it focuses on the practical issues - making it possible for a combo server to serve HTTP and WebSocket over a single port. It is agnostic as to whether the negotiation is done at the HTTP level, the TLS level, or something else completely. Whereas "HTTP compliant" assumes that the negotiation will be at the HTTP level.

> 
>> 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
> 
> 
> 
> 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi