Re: [hybi] Ticket#1 Http Compliance

[Maciej Stachowiak <[e-mail]>]

On May 13, 2010, at 1:51 AM, Greg Wilkins wrote:

> Maciej Stachowiak wrote:
> 
>> What is the difference between "HTTP/1.1 compatible" and "HTTP/1.1
>> compliant"? I can't tell if I support this change without understanding
>> what difference is intended
> 
> The intent of changing to compliant is to strengthen this requirement.
> Compliant implies that no part of the HTTP specification will
> be violated.

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?


> However,  I remind you that this requirement is only in the
> explicit circumstances of when websocket is running on
> a port shared with HTTP.
> 
> When not sharing a HTTP port, a websocket protocol is
> free to have it's own handshake (that may be HTTP-like
> or a non compliant variation of HTTP).

Having two different handshakes would not be a good idea. Also, the 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.

> 
>>>  RFC-2616 5.1.1  The methods GET and HEAD MUST be supported by all
>>>     general-purpose servers.  All other methods are OPTIONAL
>> 
>> If this implies that all WebSocket servers, even WebSocket servers that
>> are standalone and not combined with HTTP servers, must implement GET
>> and HEAD, then that seems like a silly and pointless requirement. What
>> would be the practical benefit of this?
> 
> This says the exact opposite.
> 
> A standalone websocket server is not a general purpose
> HTTP server, so this requirement does not apply.  Thus there are
> no methods that must be implemented.
> 
> 
>>>  RFC-2616 6.1.1  HTTP applications are not required to understand the
>>>     meaning of all registered status codes, though such understanding
>>>     is obviously desirable.  However, applications MUST understand the
>>>     class of any status code, as indicated by the first digit, and
>>>     treat any unrecognized response as being equivalent to the x00
>>>     status code of that class
>> 
>> What if anything does this imply for WebSocket clients and servers?
> 
> Nothing - and that is the point.
> 
> It is indicating that HTTP compliance does not require a websocket
> implementation (even one operating on a shared port) to implement
> any specific status codes.
> 
> 
> 
>>>  RFC-2616 7.1  Unrecognized header fields SHOULD be ignored by the
>>>     recipient and MUST be forwarded by transparent proxies.
>> 
>> It's not clear how this requirement constrains the design of the
>> protocol. For example, if WebSocket made the handshake fail if any
>> header fields are present other than a short whitelist, that would be
>> fully consistent with this conformance requirement.
> 
> It's not intended to constrain the design of the protocol.
> 
> IT is indicating that HTTP compliance does not require a
> websocket implementation (even one operating on a shared port) to
> implement any specific headers.
> 

Listing parts of the HTTP RFC that would have no effect on the protocol design seems unhelpful, especially since the framing material implies they *are* relevant to requirements on the protocol. It seems like none of the three cited requirements would have any particular effect on the design of the WebSocket protocol, from your explanations above.

Regards,
Maciej