Ambiguity on setting a cookie with "" (empty string) as the path.

[RupinMittal]

The spec (https://wicg.github.io/cookie-store/#set-a-cookie) says that if set is called with a path passed in, and the path does not start with a "/", then we should return a failure. This implies that passing in "" should cause a failure.

However, Chrome does not return failure here, but rather fills in the path itself and sets the cookie.

Which is correct? Returning a failure or filling in the path automatically if an empty string is passed in? Thank you!

[RupinMittal]

CC @annevk @szewai @cdumez

[johannhof]

I don't think I have a strong opinion on this, though of course changing this might lead to backwards incompat. @DCtheTall @inexorabletash @ayuishii?

[inexorabletash]

Agreed - no strong feelings either way. Logically, feels like a Chromium bug but also seems harmless to support if needed for compat. Does the FF impl treat this as an error? If so that could inform compat risk.

[annevk]

cc @bakulf

[annevk]

@RupinMittal what does "fills in the path itself" mean? Does it take the path from the url argument?

[cdumez]

Agreed - no strong feelings either way. Logically, feels like a Chromium bug but also seems harmless to support if needed for compat. Does the FF impl treat this as an error? If so that could inform compat risk.

My understanding is that Firefox is not shipping this API yet, though they are actively working on it. We could maybe check their behavior using a nightly build but I don't think it would inform compat risk?

[inexorabletash]

Since Moz has already done some amount of compat consideration about shipping only a subset of the API that Chrome shipped, I was hoping they might have noticed any issues here as well. A bit of a stretch, though.

[RupinMittal]

Firefox:
I was not able to confirm its behavior. I used a nightly build (Jan 6 build), but was not able to set any cookies using the Cookie Store API even though the feature flag was turned on. Is this API functional on FF currently? It seems from wpt.fyi that layout tests are indeed passing. Maybe I'm doing something wrong?

Chrome:
Yes, if you pass in an empty string for the path, It takes the path from the url. But ignoring the empty string feels odd. The logic seems to be:

• If no path passed in, use the default "/"
• If empty string passed in, ignore it and take the path from the url
• If non-empty string passed in, check it and set cookie if valid

As opposed to:

• If no path passed in, use the default "/"
• If path passed in, check it and set cookie if valid

[asutherland]

In Firefox, I was able to set cookies on Nightly at https://worker-playground.glitch.me/ specifically pasting in code like the following based on https://developer.mozilla.org/en-US/docs/Web/API/CookieStore#examples:

const day = 24 * 60 * 60 * 1000;

cookieStore
  .set({
    name: "cookie1",
    value: "cookie1-value",
    expires: Date.now() + day,
    domain: "worker-playground.glitch.me",
    path: "",
  })
  .then(
    () => {
      console.log("It worked!");
    },
    (reason) => {
      console.error("It failed: ", reason);
    },
  );

The code currently likes to normalize an empty path to be / and that's what I observe in our devtools storage tab afterwards:

nsString path(aPath);
if (path.IsEmpty() || path[path.Length() - 1] != '/') {
  path.Append('/');
}

Firefox currently use a gating pref that is only defaulted to true in our nightly builds. Bug 1937477 tracks enabling it to ride the trains to release.

[annevk]

I guess I don't have a strong preference, but it does seem like a bit of a footgun that the empty string gives you the path of the URL. Equivalent to not passing it (thus /) or failure seem both much more appropriate.

(I could see an argument for the current behavior if the restriction on starting with / wasn't there. In which case you could parse it as a URL and use the resulting path. But it seems weird for only the empty string to be treated as such and not foo and the like.)

[DCtheTall]

RFC 6265bis actually does instruct how to handle empty Path strings: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis#name-the-path-attribute-2

If the attribute-value is empty or if the first character of the attribute-value is not %x2F ("/")... Let cookie-path be the default-path.

So I think Chrome's behavior is actually correct here.

The Cookie Store API spec should not instruct callers to reject cookies whose Path string is empty, that seems like a spec bug.

[annevk]

If we are to take that literally it would mean that we'd also have to treat an input of "foo" as meaning the URL's path.

In my mind the API is quite distinct from the parser, but I'm okay on aligning with Chrome and special casing the empty string as that's probably the path of least resistance.

(Note that we also still have #223 on paths.)

[DCtheTall]

Ah yes I see what you mean. Perhaps the empty string should be special cased in the Cookie Store API spec.

I can add telemetry to Chrome to see how often we encounter this in the wild. If it's not that much I would be more open to changing the current behavior.