Re: [hybi] Ticket#1 Http Compliance

[Roberto Peon <[e-mail]>]

On Wed, May 12, 2010 at 6:41 AM, Greg Wilkins <[e-mail]> 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.
>

On the handshake? Which features, specifically? I'm asking because the two
sentences here come in fundamental conflict.. It is HTTP/1.1, but not
really.
I'd expect something like:

On a connection established with the expectation that the primary or first
protocol spoken is not WebSocket, the connection shall be considered that
protocol and not WebSocket until a successful UPGRADE or similar
change-of-protocol request is acknowledged. In the case of HTTP,
WebSocket-only server implementations are required to implement the
following subset of rfc2616, but are not required to implement any more than
that.


I apologize for the fast-and-loose verbiage here, but I hope I'm conveying
my intent properly!
-=R


>
>   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
>
>
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>
>