-
Notifications
You must be signed in to change notification settings - Fork 341
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrate with new draft cookie spec (draft-annevk-johannhof-httpbis-cookies/00+ε) #1807
base: main
Are you sure you want to change the base?
Conversation
This patch does the following to the work in whatwg#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" -> "<code>foo</code>") - 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.
fb9259d
to
4aa94f8
Compare
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.
This should be good, assuming whatwg/html#10991, whatwg/html#10990, and whatwg/html#8036 all land. |
<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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"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.
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!) |
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:
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):
Tests are written and can be reviewed and commented upon at:
Implementation bugs are filed:
MDN issue is filed: n/a
The top of this comment includes a clear commit message to use.
Preview | Diff