- From: Watson Ladd <watsonbladd@gmail.com>
- Date: Thu, 5 Dec 2024 16:40:18 -0800
- To: Rory Hewitt <rory.hewitt@gmail.com>
- Cc: Daniel Veditz <dveditz@mozilla.com>, Willy Tarreau <w@1wt.eu>, Daniel Stenberg <daniel@haxx.se>, David Benjamin <davidben@chromium.org>, Stefan Eissing <stefan@eissing.org>, Yoav Weiss <yoav.weiss@shopify.com>, David Schinazi <dschinazi.ietf@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Dec 5, 2024, 9:26 AM Rory Hewitt <rory.hewitt@gmail.com> wrote: > > I've seen a number of companies I've worked with using a combination of Web Storage and Local Storage to store state info locally on the browser, updating it using a cookie which has a Base64-encoded value. It obviates the need to pass every cookie back and forth with every request/response and it ensures that the cookie contains only a subset of (always allowed) characters. These customers wrote client code to handle updates to webStorage and localStorage in a similar manner to how they read/update cookies. I'm not sure how I should feel about that. It does make sense that you would end up with this, but why not put the state in the responses and requests? > > > I'm wondering whether there could be some browser support for a standard mechanism like this, which uses domain-specific protected portions of browser storage... I think at its most general this becomes "I heard you like HTTP, so I put a request in your request". There's several ways in which applications and sites use cookies, and I think the closer they get to a general purpose state synchronization mechanism the less sensible it becomes to do that vs. REST. 1: Storing a limited degree of preference/interaction information directly or auth 2: Storing a session identifier that keys a complex bit of server state 3: Complex mishmash of state from subcomponents 4: Add on to this list all the hideous things you can imagine. And the solutions for 1 and 2 are likely very different from 3 and 4, and it's not clear we even want to solve them. There's also some overlap with the state transport proposals we've seen. Sincerely, Watson > > On Wed, Dec 4, 2024 at 6:01 PM Daniel Veditz <dveditz@mozilla.com> wrote: >> >> On Mon, Dec 2, 2024 at 10:28 PM Willy Tarreau <w@1wt.eu> wrote: >>> >>> Among the needs I've identified quite a few times in the field [...] >>> >>> 2. the difficulty to store arbitrarily long cookies >> >> >> That should be more than difficult: the cookie specs have always explicitly forbidden arbitrarily long cookies. The practical limits imposed by servers and the network are even less than the spec allows. >> >>> 3. the difficulty to purge all cookies associated with a given session >> >> >> A `Clear-site-data: cookies` response header will do that in browsers these days, if "given session" means all the cookies for the entire domain and not some subset of that. >> >> -Dan Veditz > > > > -- > Rory Hewitt > > https://www.linkedin.com/in/roryhewitt
Received on Friday, 6 December 2024 00:40:34 UTC