Re: [hybi] #1: HTTP Compliance

[Ian Hickson <[e-mail]>]

On Mon, 17 May 2010, Greg Wilkins wrote:
> > 
> > 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?
> 
> 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.

This is just an HTTP server getting a request it doesn't want to handle -- 
it's perfectly allowed to do whatever it wants from an HTTP point of view, 
and the Web Socket client will disconnect once it sees the handshake is 
not what a Web Socket server would send.

Again, I don't see a problem here.


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

Clients can do whatever they want in their user interface. Nothing in the 
spec restricts that.


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

Handling redirects is remarkably complex due to the origin model. Handling 
401s used to be in the spec but was removed based on implementation 
feedback. There's no point us requiring stuff that implementors won't 
implement. (It's not really clear what the UI should be for a 401, since 
the user doesn't know he sent a request. Just prompting the user 
unexpectedly isn't an option because it habituates users to behaviour that 
is too easily replicated by phishing scams.


> Please try reading some of the many examples that I have sent in detail, 
> but in summary:
> 
>   + authentication cookie missing

Why wouldn't this be handled either in the subprotocol or (more likely) by 
the JS before it invokes the WebSocket constructor?


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

These all seem like variants on the same basic idea: the script tried to 
connect to the server, but the connection failed. There are many more ways 
the connection can fail:

   + man in the middle proxy doesn't let it go through
   + server is overloaded and times out
   + server is offline
   + user is not connected to the network
   + server's DNS is misconfigured

The list goes on. In all of these cases, the script gets an "error" 
event. We can't report anything else to the script, because that would be 
an information leak (e.g. it would let you study intranet topologies). The 
user agent can tell the user whatever it wants, though, that's fine. 
Developers would probably want to see the exact bytes sent back by the 
server, and user agents can definitely expose that.


On Mon, 17 May 2010, Dave Cridland wrote:
>
> Currently, in the XMPP world, there is BOSH. BOSH is a comet-like 
> mechanism for tunelling XMPP (and other things) through HTTP. The URI is 
> sometimes inherent in the client as delivered over HTTP; but it is also 
> sometimes hand configured.
> 
> It makes sense that if we were to use WebSockets in a similar way, then 
> a desktop client might initiate a session with an HTTP service without 
> knowing a priori if it's an HTTP or WebSocket service.

I don't understand how that could happen. Could you elaborate on what kind 
of desktop client you mean? When would you ever connect to a port without 
knowing ahead of time what protocol you want to talk?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'