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

[Zhong Yu <[e-mail]>]

On Thu, Dec 9, 2010 at 7:09 PM, John Tamplin <[e-mail]> wrote:
> 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.

I don't get HTTP-only cookie. If hostile JS is running, it has access
to everything that user has access to. It doesn't know the exact value
of http-only cookie, or TCP seq number, but it doesn't care.

(Allow me vent a little bit. HTTP-only cookie is a retarded invention.
If an application uses HTTP-only cookie, it should be banned by
browser, because it admits and advertises that it has no confidence
what code is running - so browser shouldn't run 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?

Good questions, but answerable questions. Now think about all the
questions we can raise against cookies, and whether they can be
answered.

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

I don't think that's a right angel. Comet is a workaround at the
absence of WS. It was forced to take the HTTP form, and the cookies
come with it. It wasn't a conscious choice to include cookies with
Comet. And we are not obligated to repeat it.

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

OK. But what exactly does an XHR request do with cookies today? That's
the problem, it is severely underspecified. Should WS join the party,
and do its part to increase the uncertainty?

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

I imagine that because of the stateful nature of WS, needs of cookies
will be greatly cut. Developer may have to transfer the value of one
HTTP cookie to WS, but that's about it. I don't believe that's even
slightly difficult to developers. They have no problems with Flash
sockets interacting with HTTP cookies.

I would much prefer a lean mean protocol that can be understood in
full, and developer can build things on top of it with confidence,
than a fat messy protocol that's very difficult to grasp and master -
even to the protocol authors themselves.