0

RFC 6265 provides the following algorithm for computing the default path that a cookie should be applicable to in cases where a Path attribute is not present:

The user agent MUST use an algorithm equivalent to the following algorithm to compute the default-path of a cookie:

  1. Let uri-path be the path portion of the request-uri if such a portion exists (and empty otherwise). For example, if the request-uri contains just a path (and optional query string), then the uri-path is that path (without the %x3F ("?") character or query string), and if the request-uri contains a full absoluteURI, the uri-path is the path component of that URI.

  2. If the uri-path is empty or if the first character of the uri- path is not a %x2F ("/") character, output %x2F ("/") and skip the remaining steps.

  3. If the uri-path contains no more than one %x2F ("/") character, output %x2F ("/") and skip the remaining step.

  4. Output the characters of the uri-path from the first character up to, but not including, the right-most %x2F ("/").

Let's take the example of receiving a Set-Cookie header with no Path attribute from https://example.com/a/b/c. In this case, uri-path is /a/b/c. There is no trailing slash, and therefore, if I'm interpreting the spec correctly, isn't the "right-most" slash is the one before c, and therefore the cookie-path is /a/b?

Another way of asking is, if a modern, spec-compliant browser received a cookie with no Path attribute (or any attributes besides name=value for that matter) from https://example.com/a/b/c, should that cookie be sent in a subsequent request to https://example.com/a/b?

Community
  • 1
  • 1
Todd Menier
  • 37,557
  • 17
  • 150
  • 173

1 Answers1

1

There is no trailing slash, and therefore, if I'm interpreting the spec correctly, isn't the "right-most" slash is the one before c, and therefore the cookie-path is a/b?

Almost. From 1, uri-path would be /a/b/c. 2 and 3 don't apply. From 4, the output would be /a/b, with the leading / included.

Another way of asking is, if a modern, spec-compliant browser received a cookie

If you mean actual browsers, this isn't exactly the same question; have you found an interpretation that differs?

There is still divergence from the spec, and a resource like the web-platform-tests dashboard for cookies/path may be a better resource to confirm modern browser behaviour.

However, to answer in terms of the spec:

received a cookie with no Path attribute ... from https://example.com/a/b/c, should that cookie be sent in a subsequent request to https://example.com/a/b?

Yes, because the algorithm in 5.1.4 means the default-path of the cookie is /a/b, and this path-matches /a/b because

The cookie-path and the request-path are identical.

Joe
  • 29,416
  • 12
  • 68
  • 88
  • 1
    Thanks! Just a little background. I have a fairly popular [HTTP library](https://github.com/tmenier/Flurl). It's got some new features around cookies out in a prerelease. A couple months ago I commented in [this popular answer](https://stackoverflow.com/a/43336097/62600) that I suspected he got part of it wrong. Didn't hear back, assumed I misinterpreted the spec, implemented per his answer, and now I have [this bug](https://github.com/tmenier/Flurl/issues/560) making me rethink it all! – Todd Menier Oct 24 '20 at 13:55
  • It all comes down to whether "right-most /" implies it's necessarily at the _end_ of the string. That's not how I interpret it, and good to find someone who concurs. – Todd Menier Oct 24 '20 at 13:58