[hybi] Ticket#1 Http Compliance

[Greg Wilkins <[e-mail]>]

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.

   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:

   RFC-2616 5.1.1  The methods GET and HEAD MUST be supported by all
      general-purpose servers.  All other methods are OPTIONAL
   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
   RFC-2616 7.1  Unrecognized header fields SHOULD be ignored by the
      recipient and MUST be forwarded by transparent proxies.


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.

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.

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.


regards