Re: [ServiceWorker] Add cookie accessor/setter methods? (#707)

It does occur to me that restricting to same-origin cookies might prevent @cramforce's original use case :-/.

Also as @bsittler reminds us it sounds like the key is not id, but instead id + path + other stuff.

With that in mind I have two proposals. One is based on a simplified model: path is always "/", secure is always true, httponly is always false, and same-origin means no domain. So the keys can just be strings. The other is more full-featured, adding path and domain and dropping the same-origin restriction (but keeping secure-only).

## Simplified

```
[Exposed=(Window,Worker)]
interface CookieJar {
  Promise<Cookie> get(DOMString id);
  Promise<boolean> has(DOMString id);
  Promise<void> set(DOMString id, Cookie cookie);
  Promise<void> delete(DOMString id);

  // These are annoying because maybe they should be async iterators instead...
  Promise<sequence<DOMString>> keys();
  Promise<sequence<Cookie>> values();
  Promise<sequence<sequence<DOMString or Cookie>>> entries(); // haha WebIDL
};

dictionary CookieOptions {
  DOMTimeStamp expires; // incoming Dates will be auto-converted
}

[Constructor(DOMString value, optional CookieOptions options),
Exposed=(Window,Worker)]
interface Cookie {
  readonly attribute DOMString value;
  readonly attribute DOMTimeStamp expires;
  
  // Immutable for simplicity.
}

// usage:
const original = window.cookies.get("key");
const updated = new Cookie(
    original.value + "\nanother week",
    { expires: original.expires + 7 * 24 * 60 * 60 * 1000 }
 );

window.cookies.set("key", updated);
```

This looks kind of like async local storage with expiration built-in, heh.

## Full-Featured

This version could potentially be the same just with domain and path:

```js
partial dictionary CookieOptions {
  USVString domain; // defaults to location.origin (*not* host)
  USVString path = "/";
}

partial interface Cookie {
  readonly attribute USVString domain;
  readonly attribute USVString path;
}
```

However I am unsure how well the string-keyed get/set/has/delete can work given that the key is actually something like `{ id, domain, path }`.

- Maybe we add a extra optional `{ domain, path }` parameter to get/has/delete?
  - If that's present do we do exact matching, or some kind of what-you're-allowed-to-access matching?
  - E.g., does passing `{ path: "/" }` match cookies set with `path: "/a/b/c"` when used inside /index.js?
-  Do we need a getAll so that given an ID you can get the various domain/path-varying cookies that match it?
- Does the keys/values/entries thing work well here or fall down flat? (Probably the latter.)

---

Alternately we can just say that cookies are stupid and putting lipstick on that pig is not a good idea.

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/707#issuecomment-110460810