Re: [hybi] Web sockets and existing HTTP stacks

[Mridul Muralidharan <mridulm80 at yahoo.com>]

----- Original Message ----
> From: Jamie Lokier <jamie at shareable.org>
> To: Mridul Muralidharan <mridulm80 at yahoo.com>
> Cc: Mark Nottingham <mnot at mnot.net>; Roberto Peon <fenix at google.com>; hybi at ietf.org
> Sent: Wed, 3 February, 2010 7:14:32 AM
> Subject: Re: [hybi] Web sockets and existing HTTP stacks
> 
> Mridul Muralidharan wrote:
> > There is a difference between sending an upgrade request, which is
> > conforment with http spec - and so intermediaries/others being able to
> > make a decision about whether to allow/honour it or not, and doing it
> > by fudging requests by making it look like http.
> >
> > I am all for using http in the way it is meant to be used - even for
> > bootstrapping non-http protocols : if done right, which is not opaque
> > : but not when trying to piggyback on 'port 80 is open, let us use it
> > since admin cant stop us'.
> 
> In case you hadn't checked, WebSocket actually does use the HTTP
> Upgrade mechanism.  Firewalls which block HTTP Upgrade requests based
> on the request and response headers can include blocking WebSocket, or
> not as they choose, in their rules.
> 
> In this regard, there is no fudging.
> 
> The rigidity of WebSocket's spec forces senders to be more rigid in
> what they send, and receivers to be more strict in what they accept.
> This has the side effect that proxies which modify the request will
> sometimes break it.  But it does not prevent HTTP firewall function,
> as long as it doesn't modify the messages when it's allowing them to
> pass.

I will need to recheck the latest draft spec later today, but my understanding was the it does not honour redirects, auth requests (proxy or server), insertion of arbitrary headers (c -> p1 -> p2 -> s) , reordering of headers, etc.
Hopefully these are resolved now.
If they are indeed resolved, I dont see the problem with bootstrapping using UPGRADE.


On a related note, an oft repeated assumption is that client and server would be developed by the same 'person/team/company' - this, I believe, is very short sighted.
As we have seen it in xmpp space, well defined protocols leads to explosion of client side libraries for various languages, frameworks, etc : allowing you to talk to any compliant server.




> 
> > [Think using CONNECT to start sending arbitrary protocols : it is
> > done a lot, but reason for having CONNECT enabled in proxies is not
> > for arbitrary protocols, but just https].
> 
> Just a random FYI, CONNECT and port 443 are blocked in some locations,
> because they want to be able to inspect all HTTP requests and block
> those they can't inspect.

Exactly my point, I would not like it as a user (if I cared about it  : since this means I cant connect to my bank),  but I would definitely want this ability if I were an admin.
The ability to monitor & control access is very useful and probably fundamental.


Regards,
Mridul

> 
> -- Jamie



      The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/