Integrate with new draft cookie spec (draft-annevk-johannhof-httpbis-cookies/00+ε) #1807

bvandersloot-mozilla · 2025-01-30T13:58:22Z

This adds algorithms to retrieve and store cookies via the new draft cookie spec, assuming we have some more partitioning arguments.

It is based on #1707, and in total it does the following:

lift samesite logic from 6265bis
append cookies to requests
pull cookies from responses
define partition keys for fetches
define when unpartitioned cookies cannot be used

This blocks on some HTML changes

This patch does the following on top of the work in #1707:

rebase to main
add logic for parsing and storing cookies
point to the IETF-hosted draft cookie spec
don't point to storage access API for has storage access, use a broken link instead
add a broken link to environment/ancestry
add a broken link for the request's initiator origin plumbed in from HTML. It'll be defined here, but we need to modify HTML so we can track it in the top.
add broken links to things that need to be added to HTML
fix some nits (e.g. "foo" -> "foo")
use [=secure context=] not scheme=https
use SameSite=None by default. Let's punt on that for now, given the current state of implementations and lack of clear path forward.
At least two implementers are interested (and none opposed):
- Mozilla
- Apple
- Google
Tests are written and can be reviewed and commented upon at:
- This shouldn't change functionality.
Implementation bugs are filed:
- Chromium: n/a
- Gecko: n/a
- WebKit: n/a
MDN issue is filed: n/a
The top of this comment includes a clear commit message to use.

Preview | Diff

bvandersloot-mozilla · 2025-01-30T13:59:18Z

@DCtheTall @annevk

This is a concept that originated in the Storage Access API, where it has been stuck because of spec issues between Fetch and 6265bis. To un-logjam this, I've started whatwg/fetch#1807. That depends on this bit existing. This patch adds the bit, which remains false, and does nothing.

To un-logjam the cookie layering work, I've started whatwg/fetch#1807. That depends on this info to be piped into Fetch so we can actually specify in WHATWG what SameSite=Strict means. This patch plumbs that through on top-level navigatable fetches. This doesn't build because it relies upon the corresponding patch in Fetch. Let me know to land these.

bvandersloot-mozilla · 2025-02-04T17:07:40Z

This should be good, assuming whatwg/html#10991, whatwg/html#10990, and whatwg/html#8036 all land.

johannhof · 2025-02-12T21:08:55Z

fetch.bs

-       <a href=https://httpwg.org/specs/rfc6265.html#cookie>section 5.4</a> of
-       [[!COOKIES]]) with the user agent's cookie store and <var>httpRequest</var>'s
-       <a for=request>current URL</a>.
+     <p class=note>This permits some implementations to choose to not support cookies for some or all <var>httpRequest</var>s.


"This" here refers to the word "should" in the line below? I'm not a huge fan of that, both because it's a bit subtle and also because it doesn't account for the opposite case: All major browsers have settings / overrides that will allow cross-site cookies to be sent, so I think it would be preferable to insert a step that allows user agents to make an additional implementation defined choice about whether to include cookies or not. It might have to live in the append a request Cookie header algorithm.

Obviously this should be reserved for truly implementation-specific settings and anything else should be standardized here.

johannhof · 2025-02-12T21:47:32Z

I think this PR series looks great to me overall, but I also think we should wait for HTTP WG adoption of the new cookies spec before seriously moving forward with this (should do the reviews now, though!)

bvandersloot-mozilla · 2025-03-03T19:48:03Z

I've removed the partitioning bits from this, and will make them as a separate PR after we've merged this

annevk

Thanks Ben for driving this forward. This definitely looks like the correct approach.

annevk · 2025-03-07T10:46:55Z

fetch.bs

-return true:
+<p>A <a for=/>request</a> has a <dfn for=request id=concept-request-redirect-taint>redirect-taint</dfn>,
+which is "<code>None</code>", "<code>Cross-Origin</code>", or "<code>Cross-Site</code>".
+<p>To get <a for=/>request</a> <var>request</var>'s <a>redirect-taint</a>:


Enum values, including internal enum values, are lowercase.

annevk · 2025-03-07T10:48:19Z

fetch.bs

   <li><p>If <var>url</var>'s <a for=url>origin</a> is not <a>same origin</a> with
   <var>lastURL</var>'s <a for=url>origin</a> and <var>request</var>'s <a for=request>origin</a> is
-   not <a>same origin</a> with <var>lastURL</var>'s <a for=url>origin</a>, then return true.
+   not <a>same origin</a> with <var>lastURL</var>'s <a for=url>origin</a>,
+   then let <var>crossOriginTaint</var> be "<code>Cross-Origin</code>"..


Should this be "same-site" or "same-site-cross-origin"?

Also, you overwrite a variable with "set" and "to". "Let ... be" is only for initializing.

Single dot at the end here too.

annevk · 2025-03-07T10:50:16Z

fetch.bs

@@ -2489,6 +2518,9 @@ this is also tracked internally using the request's <a for=request>timing allow
 <p>A <a for=/>response</a> has an associated <dfn for=response>has-cross-origin-redirects</dfn>
 (a boolean), which is initially false.

+<p>A <a for=/>response</a> has an associated <dfn for=response>has-cross-site-redirects</dfn>
+(a boolean), which is initially false.


Hmm, it strikes me that we should turn these two into a "redirect taint" enum for responses?

annevk · 2025-03-07T10:51:32Z

fetch.bs

@@ -3292,6 +3324,72 @@ through TLS using ALPN. The protocol cannot be spoofed through HTTP requests in

 <h2 id=http-extensions>HTTP extensions</h2>

+<h3 id=cookie-header>`<code>Cookie</code>` header</h3>
+
+<p>The `<dfn export http-header id=http-cookie><code>Cookie</code></dfn>`


I don't think it's appropriate to <dfn> it. We should do this more akin to Content-Type.

annevk · 2025-03-07T10:52:22Z

fetch.bs

+
+<div algorithm>
+<p>To <dfn id=append-a-request-cookie-header>append a request `<code>Cookie</code>` header</dfn>,
+given a <a for=/>request</a> <var>request</var>, run these steps:


Suggested change

given a <a for=/>request</a> <var>request</var>, run these steps:

given a <a for=/>request</a> <var>request</var>:

Modern style is just "To DO X given Y y:"

annevk · 2025-03-07T10:52:38Z

fetch.bs

+<p>To <dfn id=append-a-request-cookie-header>append a request `<code>Cookie</code>` header</dfn>,
+given a <a for=/>request</a> <var>request</var>, run these steps:
+  <ol>
+     <li><p>Let |sameSite| be the result of [=determining the same-site mode=] for <var>request</var>.


Indentation is wrong here.

annevk · 2025-03-07T10:55:11Z

fetch.bs

+  <ol>
+     <li><p>Let |sameSite| be the result of [=determining the same-site mode=] for <var>request</var>.
+     <li><p>Let |isSecure| be false.
+     <li><p>If <var>request</var>'s <a for=request>client</a> is a <a>secure context</a>, then set |isSecure| to true.


Isn't it strictly based on the URL scheme?

annevk · 2025-03-07T10:55:50Z

fetch.bs

+
+     <p class=note>It is expected that the cookie store returns an ordered list of cookies
+     <li>If |cookies| <a for="list">is empty</a>, then return.
+     <li>Let |value| be the result of running <a>serialize cookies</a> given |cookies|.


annevk · 2025-03-07T11:00:54Z

fetch.bs

@@ -3292,6 +3324,72 @@ through TLS using ALPN. The protocol cannot be spoofed through HTTP requests in

 <h2 id=http-extensions>HTTP extensions</h2>

+<h3 id=cookie-header>`<code>Cookie</code>` header</h3>


I think we need a dedicated Cookies section and the the Cookie header can be one part of that.

The other part will need to tackle johannhof/draft-annevk-johannhof-httpbis-cookies#13. In particular defining requirements for user agents around clearing cookies and how those changes are propagated across documents. At least I think we want all of the architecture to be handled by Fetch and then have HTML, Cookie Store API, and Service Workers (although maybe no Service Workers changes are required? I don't recall) call into that.

fetch.bs

Co-authored-by: Anne van Kesteren <[email protected]>

bvandersloot-mozilla changed the title ~~Integrate with new draft cookie spec (draft-annevk-johannhof-httpbis-cookies/00++)~~ Integrate with new draft cookie spec (draft-annevk-johannhof-httpbis-cookies/00+ε) Jan 30, 2025

bvandersloot-mozilla force-pushed the main branch from fb9259d to 4aa94f8 Compare February 4, 2025 16:25

This was referenced Feb 4, 2025

Add "has storage access" boolean to environment whatwg/html#10990

Open

Pass a top-level navigation initiator origin to Fetch whatwg/html#10991

Open

bvandersloot-mozilla mentioned this pull request Feb 4, 2025

Add cross-site ancestor flag to environment. (privacycg/storage-parti… whatwg/html#8036

Open

3 tasks

johannhof reviewed Feb 12, 2025

View reviewed changes

bvandersloot-mozilla force-pushed the main branch from 4aa94f8 to 0994460 Compare March 3, 2025 19:45

Cookie layering, part 1: only the same-site stuff

aef5c9d

bvandersloot-mozilla force-pushed the main branch from 0994460 to aef5c9d Compare March 4, 2025 20:32

annevk reviewed Mar 7, 2025

View reviewed changes

cfredric mentioned this pull request Mar 10, 2025

Introduce request infrastructure for storage access privacycg/storage-access#214

Open

3 tasks

apologies for American

7a6a1fe

Co-authored-by: Anne van Kesteren <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Integrate with new draft cookie spec (draft-annevk-johannhof-httpbis-cookies/00+ε) #1807

Integrate with new draft cookie spec (draft-annevk-johannhof-httpbis-cookies/00+ε) #1807

bvandersloot-mozilla commented Jan 30, 2025 •

edited by pr-preview bot

Loading

bvandersloot-mozilla commented Jan 30, 2025

bvandersloot-mozilla commented Feb 4, 2025

johannhof Feb 12, 2025

johannhof commented Feb 12, 2025

bvandersloot-mozilla commented Mar 3, 2025

annevk left a comment

annevk Mar 7, 2025

annevk Mar 7, 2025

annevk Mar 7, 2025

annevk Mar 7, 2025

annevk Mar 7, 2025

annevk Mar 7, 2025

annevk Mar 7, 2025

annevk Mar 7, 2025

annevk Mar 7, 2025

	given a <a for=/>request</a> <var>request</var>, run these steps:
	given a <a for=/>request</a> <var>request</var>:

	<li>Let \|value\| be the result of running <a>serialize cookies</a> given \|cookies\|.
	<li>Let \|value\| be the result of <a>serializing cookies</a> given \|cookies\|.

		@@ -3292,6 +3324,72 @@ through TLS using ALPN. The protocol cannot be spoofed through HTTP requests in

		<h2 id=http-extensions>HTTP extensions</h2>

		<h3 id=cookie-header>`<code>Cookie</code>` header</h3>

Integrate with new draft cookie spec (draft-annevk-johannhof-httpbis-cookies/00+ε) #1807

Are you sure you want to change the base?

Integrate with new draft cookie spec (draft-annevk-johannhof-httpbis-cookies/00+ε) #1807

Conversation

bvandersloot-mozilla commented Jan 30, 2025 • edited by pr-preview bot Loading

bvandersloot-mozilla commented Jan 30, 2025

bvandersloot-mozilla commented Feb 4, 2025

Choose a reason for hiding this comment

johannhof commented Feb 12, 2025

bvandersloot-mozilla commented Mar 3, 2025

annevk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bvandersloot-mozilla commented Jan 30, 2025 •

edited by pr-preview bot

Loading