Re: [hybi] Ticket#1 Http Compliance

[Maciej Stachowiak <[e-mail]>]

Also speaking as an individual...

On May 12, 2010, at 6:41 AM, Greg Wilkins wrote:

> All,
> 
> Attached is a proposed diff (from me as individual - not as requirements editor)
> to the requirements document for HTTP Compliance.
> 
> Formatted as text the patch results in:
> 
> 
>   REQ. 7:  When sharing host and "well known" port with HTTP, the
>      WebSocket protocol MUST be HTTP/1.1 compliant until both ends have
>      established the WebSocket protocol.  The protocol may prohibit the
>      usage of specific HTTP features.

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

> 
>   Reason: when operating on the standard HTTP ports, existing web
>   infrastructure may handle connections and requests according to
>   existing standards prior to the establishment of the new protocol.
>   It may also be desirable for consenting clients and servers to use
>   HTTP features such as authentication and redirection, prior to
>   establishing the websocket handshake.
> 
>   However, this requirement does not mean that a websocket
>   implementation that is not for general-purpose HTTP, need implement
>   any more of the HTTP protocol than is required to establish a
>   websocket connection.  The minimal requirements of HTTP are small, as
>   indicated by the following extracts of RFC-2616:

I think quoting parts of the HTTP RFC in the requirements document is not a good idea. It seems like too much detail for a requirements document.

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

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

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

> 
> My intent with this wording is to not require any more of HTTP
> to be implemented my minimal implementations, hence the extracts
> from RFC2616 showing that there are few MUSTs in HTTP.

Are you claiming these are the only MUST-level requirements that apply to HTTP clients and servers? That seems wrong to me. If you are indeed claiming this I'll be glad to provide counter-examples.

> This will allow arbitrary HTTP features to be used if
> client and server desire to do so - which seams reasonable
> as in many cases the client and server are going to have
> full HTTP implementations available.

If that is indeed desirable, it seems like a separate requirement from being "HTTP compliant". The handshake could be "HTTP compliant" without enabling this.  

> 
> However, it does allow the protocol to specifically prohibit
> the use of features, if for example we decided that redirect
> was a undesirable for some reason.

I agree that we must have the freedom for the protocol to do this. But for this very reason, the change doesn't do what you said in the previous paragraph.

Regards,
Maciej