Re: [hybi] Ticket#1 Http Compliance

[Greg Wilkins <[e-mail]>]

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.

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


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

The intent is to try to communicate that requiring HTTP compliances
is not going to require additional features on minimal implementations.

There are very few MUST's in RFC2616.

The intent of this requirement is more of a you must not break HTTP
(when sharing a port) rather than a you must not implement all of HTTP.



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


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

I'm claiming that a requirement of HTTP compliance will not
require any more of the HTTP specification to be implemented
than already is.

The intent of this requirement is not to force any more
implementation of the HTTP specification.    It is to
prevent the protocol breaking the HTTP specification when
sharing a port with a general purpose HTTP server.



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


This is an argument for HTTP compliance as it prevents an
implementation from disabling arbitrary HTTP features (when
sharing a port with HTTP).

I think it is perfectly OK for the websocket protocol to
specifically disable a feature that is incompatible with
the handshake (eg if redirections are shown to be a security
risk).



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


It is entirely possible to limit HTTP features and still
be compliant with the HTTP RFC.

There is a big difference between the protocol choosing not
to support a HTTP feature: eg "a websocket client
shall not follow a redirect sent in response to an upgrade request"
and with the protocol being specified in such a way that
HTTP is actually broken: eg. "a websocket client shall send
non HTTP compliant data on the connection prior to the
upgrade completing".


regards