Re: [hybi] Ticket#1 Http Compliance

[Maciej Stachowiak <[e-mail]>]

On May 13, 2010, at 2:53 AM, Greg Wilkins wrote:

> 
>> How is the implication of "compatible" different from what you 
>> describe for "compliant"? Can you give an example of something
>> that would be HTTP compatible, but not HTTP compliant?
> 
> telnet is HTTP compatible as I can telnet to a HTTP server
> and interoperate with it.
> 
> telnet is not HTTP compliant as I can telnet to a
> HTTP server and do all sorts of illegal stuff.

Can you give an example that's relevant to WebSocket? Is there anything in a current or previous draft that's HTTP compatible but not HTTP compliant? That would make it easier to assess the practical impact of this change. WebSocket protocol is not in a situation where you can choose to have syntactically correct HTTP interactions or not, like telnet. It's pretty specific in its requirements.

> If you don't agree that there is significant difference between the words, then what is the problem changing?

I'd like to understand what the difference is, so that I understand the consequences of the change. I don't care that much about the word choice, but since some people apparently do, I'd like to understand what practical difference it makes. If the answer is "no difference" then I would not object.

> 
>> Having two different handshakes would not be a good idea. 
> 
> I'm not advocating that.   I'm only advocating that when you
> operate on a shared HTTP port that you are required to be
> HTTP compliant until you are upgraded.
> 
>> Also,
>> he client initiates the handshake and can't tell if the port is
>> being shared with an HTTP server, so there's no opportunity to
>> initiate the handshake differently. Making the server reply differently
>> depending on whether it is standalone, when the client handshake has
>> to be the same, would just create interop problems.
> 
> I mostly agree.  But this is a reason to always be
> HTTP compliant.  I see no reason to ever pretend to be
> HTTP without actually being HTTP compliant.   The
> overheads of being HTTP compliant are nothing.


Can you give examples of things from the current draft that are not HTTP compliant? I assume the random characters after the request are one thing. Is there anything else?

Cheers,
Maciej