Re: [hybi] Ticket#1 Http Compliance

[Greg Wilkins <[e-mail]>]

Maciej Stachowiak wrote:
> On May 13, 2010, at 2:53 AM, Greg Wilkins wrote:
>> telnet is not HTTP compliant as I can telnet to a
>> HTTP server and do all sorts of illegal stuff.
> 
> Can you give an example that's relevant to WebSocket? Is there anything in a 
> current or previous draft that's HTTP compatible but not HTTP compliant?
> That would make it easier to assess the practical impact of this change.

I believe the current -76 handshake could be described as HTTP compatible,
but it is not HTTP compliant.

The use of redirects and BASIC authentication would also be compliant
features that the current specification does not support because
it is only compatible.


> Can you give examples of things from the current draft that are not HTTP 
> compliant? I assume the random characters after the request are one
> thing. Is there anything else?

The random characters are the most obvious non compliance.

But there is also a restriction on the headers that can be sent,
which I think is boarder-line non compliance, so that
for example user-agent cannot be sent.

There is also a restriction on the server that it's only
valid responses to a handshake is to either accept with
a 101 or to close the connection.  A compliant HTTP server
should be able to respond with any compliant HTTP response.
The websocket specification can say that websocket clients
can ignore all non-101 responses and close the connection,
but they cannot require that a HTTP server act contrary
to the HTTP specification simply because a client made
some mistake in the formulation of their websocket URL (for
example).

In order to claim websocket compliance, I do not want to
have to change my server so that every URL that receives
a bad websocket upgrade has to close the connection without
sending some legal HTTP error response (eg 400 or 404).


regards