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

[Zhong Yu <[e-mail]>]

On Thu, Dec 9, 2010 at 5:46 PM, John Tamplin <[e-mail]> wrote:
> On Thu, Dec 9, 2010 at 2:42 PM, Zhong Yu <[e-mail]> wrote:
>>
>> On Thu, Dec 9, 2010 at 11:26 AM, Scott Ferguson <[e-mail]> wrote:
>> > When the draft used GET+Upgrade, servers could reuse things like the
>> > HTTP
>> > authentication, cookie headers, etc., and reuse the existing protocol
>> > stack
>>
>> I believe HTTP cookies shouldn't be included in WS, and I'll make that
>> case in time.
>>
>> http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html
>> HTTP cookie is a mess, we don't want to introduce that mess to WS. And
>> even worse, if WS interacts with cookies too, it will add yet another
>> dimension of  complexity to the existing mess. HTTP is connection-less
>> in spirit, WS is connection-ful and stateful in nature, some benefits
>> of cookies to HTTP don't apply to WS. If an app needs to transmit HTTP
>> cookies to WS app, it's easy to do without any help from WS protocol.
>> If we must have a persistent tag for different WS connections from
>> same user, we can introduce a much simpler and cleaner mechanism. But
>> say no to cookies.
>
> 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.

> of the big problems with cookies in HTTP is that you send them on every
> request so they can take up a sizeable percentage of the bandwidth of the
> request, but in WebSockets that isn't a problem.

I think that's the least of cookies' problems.

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

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.

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