Re: [hybi] Ticket#1 Http Compliance

[Greg Wilkins <[e-mail]>]

Maciej Stachowiak wrote:



> Listing parts of the HTTP RFC that would have no effect on the
> protocol design seems unhelpful

Probably true.   I added them anticipating the concerns
previously expressed that HTTP compliance would require
all implementations to support more of the HTTP protocol.

I was trying to be very clear to say that this requirement
does not mean that more of HTTP must be supported.  It is
only saying that HTTP must be respected prior to the upgrade.

Perhaps the quotes from the RFC should have only been
in my supporting email and not in the reasoning text of
the requirement.  I'm happy to remove them.



> 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.

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



> 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.


regards