Re: [hybi] #1: HTTP Compliance

[Greg Wilkins <[e-mail]>]

On 17/05/10 13:20, Ian Hickson wrote:
> On Mon, 17 May 2010, Greg Wilkins wrote:
>>
>> The server is going to have to send responses and is currently faced 
>> with a difficult (or impossible) choice between sending a HTTP compliant 
>> or a websocket compliant response.
> 
> If the server is a Web Socket server, and it received a request from a 
> Web Socket client, then why would it care about HTTP?
> 
> If the server is not a Web Socket server, then why would it ever consider 
> sending a response back using Web Sockets?
> 
> If the server is aware of Web Sockets and HTTP, and gets a request from an 
> HTTP client, then why would it respond with Web Sockets?
> 
> I really don't understand what the choice is. In every situation I can 
> see, there's an unambiguous right response.

This is not an exhaustive list and you left out the situation
that I have been describing in my examples.

   The server is aware of both web sockets and HTTP and
   receives a request from a websocket client that is
   to be rejected.

For one of the many reasons I've outlined in my other email, that
request is handled either by code that does not know about
websockets, or is unable to act as the websocket spec requires
(ie closing connection).

Thus the only possible choice is for the server to send
a compliant HTTP response, which is contrary to the websocket
specification.


> > In reality, clients and servers are going to have to talk compliant HTTP
> > to each other to deal with these cases - regardless of whatever the
> > protocol spec says.
> I have no idea what this means.

Websocket clients are going to receive 404's, 503's etc.
They are going to have to handle them sensibly and report
reasonable errors to the user.

There are also arguments that it is desirable to allow
clients to actually interpret some of these responses.
It could for example handle a 401 or a 302.


> Web Socket servers will not send 4xx and 5xx responses.
> > So you can continue to pretend that these conversations will never
> > actually happen.... but that will not change the reality that they will.
> Why would they happen?

Please try reading some of the many examples that I have sent in
detail, but in summary:

  + authentication cookie missing
  + wrong URL given to the websocket client.
  + poor deployment (with apache or similar in front or
    in a server that does not support websocket).
  + some other exception made the webapplication fail
    to start, so the container sends a 503
  + some exception in handling the request causes a 500
  + some stupid caching proxy sends a 200 response


Websocket clients are going to receive 404's, 503's etc.
They are going to have to handle them sensibly and report
reasonable errors to the user.

regards