Subject: [hybi] Cookie Problem

From: Zhong Yu <[email-masked]>
Date: Sat, 6 Nov 2010 17:40:46 -0500

If in the middle of a websocket conversation, the server decides to
set a cookie, how can that be done?

The current spec only allows set-cookie during the handshake, but not
during data exchange.

Server and client can have a proprietary set-cookie protocol over
websocket, and client script can set cookie upon receiving the frame.
But that works only if the client is in the same origin as the server.
Imagine a web service exposed as websocket to the public, accessible
to any client from any origin, the server might want to attach cookies
to users, without clients knowing.

One hack I can think of is to terminate the connection, and usually
the client app will try to reconnect, then the server has a chance to
set the cookie. A prior cookie identifying the client must already
exist, otherwise the server cannot associate the two connections.

- Zhong Yu

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 8 Nov 2010 14:05:55 +1100

Zhong,

Several of the proposals that I have previously made included
meta-data frames that could carry headers, including Set-Cookie's.

I think with the current framing, it would not be difficult to come up
with a standard extension for this - if it proves necessary.

cheers

On 7 November 2010 09:40, Zhong Yu <[email-masked]> wrote:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: John Tamplin <[email-masked]>
Date: Sun, 7 Nov 2010 22:31:17 -0500

> with a standard extension for this - if it proves necessary.

If you want the server to always have a consistent view of the relevant
cookies, setting a cookie in a regular HTTP request should be reflected in
the WebSocket connection, and you may not want to wait until the next
WebSocket request to send that data so you would essentially be tying an
external event to generating WebSocket messages.  You definitely don't want
to send all the cookies on each request (one of the problems with XHR is you
send all the cookies on every request), so for it to be viable it would have
to be some sort of delta to what is previously known.

There is a lot of complexity in exactly how this would need to be handled,
so I definitely think that for now it is much better to simply say the
cookies are transmitted at the time the connection is established and it is
up to the application to do anything about changes to the cookies.  I am not
sure exactly how a "continuous cookies" extension would work, but I suspect
it could be done if there was sufficient need.

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