Re: [hybi] Ticket#1 Http Compliance

[Greg Wilkins <[e-mail]>]

On 13/05/10 17:53, Scott Ferguson wrote:
> Greg Wilkins wrote:
>> 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).
>>   
> Agreed. This is a big issue. The server must be allowed to return a
> valid HTTP response rejecting the Upgrade request.


I'd like to expand on this point with examples, to illustrate why
I think compliance is necessary and that websocket clients
are going to end up seeing HTTP responses anyway.


A server that is both a HTTP server and a Websocket server
may use cookies to authenticate users (which is allowed
by current websocket draft).   Frequently such authentication
is implemented by a filter/handler/valve applied in front
of a web application.  Often that filter/handler/valve is
provided by a 3rd party and sometimes imposed by a different
part of an organization.

Without HTTP compliance, if that filter see's an invalid or
missing authentication cookie, then it will have to decide
if it will send a HTTP compliant response (403) or a
Websocket compliant response (close connection).  In all
likelihood, the authenticator will know nothing about
websockets (nor should it) and will send a 403 response.


Similarly, if a developer made a mistake with the URL
and attempted a websocket connection to the wrong resource,
then the request would end up in code that probably knows
nothing about websocket, and will again be faced with the
choice of sending a HTTP compliant response (404) or
a websocket compliant response (close connection).

Alternately, if a deployer made a mistake and deployed
an otherwise correct and capable websocket server&application
behind something like apache mod_jk, then code that
is fully aware of websocket would receive the upgrade
request and should reject it because it AJP13 cannot do
websocket.   However, it is not possible for this code
to just close the connection which is on a different machine
and terminated by code that does not know websocket.
So in this case, even code that does know websocket
is only able to send a HTTP compliant response.


So in all these examples, it shows that a combined
HTTP/websocket server is likely to have many situations
where the only possibility is for it to send a HTTP
compliant response.       If a HTTP compliant response
is not websocket compliant, than any problems these
responses cause with 3rd party websocket clients
are likely to be met with "its your fault because
you are not websocket compliant".


It is very clear that if a port is to be shared
with HTTP, then websocket clients WILL see
compliant HTTP responses to handshakes.
Clients will need to be written to well handle
such responses, even if in most cases all
non-101 responses are treated as failures.
But a well written client should also be able
to tell it's user the difference between a
2xx, 3xx, 4xx and 5xx etc so they might know
the reason for a failure without the need to
snoop the network.

So if HTTP compliance is required before the
handshake, it is not going to compel clients
to do anything that they would not be doing
anyway.     But it would take away the
dilemma on the server side of should a
HTTP compliant or a Websocket compliant
rejection be sent.

It would also facilitate the possible real
use of other HTTP features and minimal
RTT connection negotiation.

regards