Re: [hybi] workability (or otherwise) of HTTP upgrade

[John Tamplin <[e-mail]>]

On Thu, Dec 9, 2010 at 7:52 PM, Zhong Yu <[e-mail]> wrote:

> > The app can't send HTTP-only cookies, since it has no access to them.
>  One
>
> The *app* has access to everything that server allows it to. The
> client side code is all generated by server anyway, server can bundle
> any data to the client code.


Not if you want to associate an HTTP-only cookie with the connection such
that hostile JS can't interfere with it.


> > Whatever cookies shortcomings, they are still being used and there is no
> > viable replacement so I don't think we should drop support for them in
> > WebSockets.
>
> Of course, HTTP cookies are still useful. That doesn't mean WS should
> inherit them. We are not preventing WebSocket applications from using
> HTTP cookies or making it difficult.
>
> Because WS is stateful, the server can simply associate user state
> with connection. It doesn't need to send user state back to client,
> then ask client to send it back. That mechanism makes sense for HTTP,
> but not WS.



There is still a problem of associating multiple WS connections from
> the same user, but that is a much smaller problem than what cookies
> try to solve.
>

How does it get that first association?  What if there are separate tabs
open, with different credentials?  How does it know which one from the same
origin goes with which HTTP session?


> My real fear of cookies is from reading that blog
> http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html
> Whose head won't explode by just thinking all the new problems WS will
> add to the existing mess if it starts to interact with cookies? Of
> course, we can be likewise irresponsible, and just vaguely specify
> WS-cookie interaction, leaving many questions open.
>

Existing applications use HTTP and cookies today, including Comet/etc
applications which WebSocket is intended to replace.  Dropping cookie
support from WebSocket only adds another barrier to converting those apps to
use WebSocket.

It seems to me that WebSocket should handle cookies exactly as an XHR
request does today, which doesn't seem like it improves or makes worse any
of the issues with cookies.  If you are arguing that the app should continue
to use cookies but just manage sending them itself, how does that change
anything over WebSocket sending the cookies, other than force independent
reinvention of the wheel?

-- 
John A. Tamplin
Software Engineer (GWT), Google