Skip to content

Conversation

@annevk annevk self-assigned this Aug 12, 2025
@annevk annevk added the WebCore Misc. For miscellaneous bugs in the WebCore framework (and not JavaScriptCore or WebKit). label Aug 12, 2025
@webkit-ews-buildbot webkit-ews-buildbot added the merging-blocked Applied to prevent a change from being merged label Aug 12, 2025
@annevk
Copy link
Contributor Author

annevk commented Aug 12, 2025

This needs to use CookieUtil::defaultPathForURL instead.

@annevk annevk marked this pull request as draft August 12, 2025 14:14
@annevk annevk removed the merging-blocked Applied to prevent a change from being merged label Aug 12, 2025
@annevk annevk force-pushed the eng/Cookie-Store-API-add-branch-for-empty-string-path branch from b060803 to 1fd68bc Compare August 12, 2025 16:14
@annevk annevk marked this pull request as ready for review August 13, 2025 05:56
@annevk annevk force-pushed the eng/Cookie-Store-API-add-branch-for-empty-string-path branch from 1fd68bc to 7b2a1a7 Compare August 13, 2025 07:08
@annevk annevk requested review from RupinMittal and achristensen07 and removed request for achristensen07 August 13, 2025 07:18
return;
}

// FIXME: The specification does not perform this initialization of domain.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this code is correct and it's actually the spec that is wrong here. It says here https://cookiestore.spec.whatwg.org/#CookieStore-set (in the green box) that the domain defaults to "Domain: same as the domain of the current document or service worker’s location"

Yet the steps say "Let domain be null". I'm not sure how the spec expects the domain to be default to the same as that of the current document if it defaults to null in the steps.

I think this is a mistake in the spec maybe? Because last year, the default for domain was null (WebKit always defaulted to current document domain since CFNetwork won't let us set cookies with null domain). At some point the spec default was changed to current document domain but maybe they forgot to change in the steps?

(Contrast this with path, whose default is "/" and steps indeed start it off with "/"). Of course, the default is being changed in this patch here, but still the spec will be consistent in both places for path. It looks like a change needs to be made for domain to be consistent.

Copy link
Contributor Author

@annevk annevk Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what the network layer ends up defaulting domain to. The domintro box is arguably a bit misleading, but it's also non-normative and not aimed at implementers.

Copy link
Contributor

@RupinMittal RupinMittal Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, the comment is ok. I do remember that when implementing, I had to add this even though the spec didn't have it because setting cookies simply doesn't work without it (due to our network layer). Hence that one bug I filed. Then at some point I saw that the domintro box was changed, so I thought that the spec had in fact changed from default null to the current context's domain. And I thought great! Our quirk is correct now.

But I'm now realizing from your comment that's not fully true, and we're still figuring out that area. So yes, the comment is ok for now.

promise->reject(Exception { ExceptionCode::TypeError, "If the cookie name begins with \"__Host-\", the path must either not be specified or be \"/\"."_s });
return;
}
// FIXME: This should be further down.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like the spec should figure out the steps of where it wants to set the default domain (see my below comment), which will tell us where this should go.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a separate problem from what this PR is tackling though. I was hoping to tackle that next, though I think the changes will be mostly on our side.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. Yeah since you're working on this area, I think the FIXME is ok for now then.

promise->reject(Exception { ExceptionCode::TypeError, "The path must begin with a '/'"_s });
return;
}
ASSERT(!cookie.path.isNull());
Copy link
Contributor

@RupinMittal RupinMittal Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not possible for this to happen. CookieInit::path is default initialized to "/". Perhaps we can remove this assertion.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to remove it. The previous code checked for it being null so I thought I'd clarify that's not possible.

Copy link
Contributor

@RupinMittal RupinMittal Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually yeah good point. It also doesn't hurt to have that there. Also a good safeguard just in case we change the default for path later too.

Let's keep it.

}

if (cookie.path != "/"_s && cookie.name.startsWithIgnoringASCIICase("__Host-"_s)) {
promise->reject(Exception { ExceptionCode::TypeError, "If the cookie name begins with \"__Host-\", the eventual path must be \"/\"."_s });
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: What's the point of "eventual" here? Perhaps it's most clear to simply say "... the path must be "/".

Copy link
Contributor

@RupinMittal RupinMittal Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I get it. You're trying to explain the whole "it should either be "/" or empty so it can default to that" in a nice way.

Maybe we can say ... the path must be either be specified as "/" or not be specified so it defaults to "/". to make it clear to the developer.

@annevk annevk force-pushed the eng/Cookie-Store-API-add-branch-for-empty-string-path branch from 7b2a1a7 to 91f4b2b Compare August 14, 2025 07:08
Copy link
Contributor

@RupinMittal RupinMittal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great :)

@annevk annevk added the unsafe-merge-queue Applied to send a pull request to merge-queue, but skip building and testing label Aug 14, 2025
@webkit-commit-queue webkit-commit-queue force-pushed the eng/Cookie-Store-API-add-branch-for-empty-string-path branch from 91f4b2b to 2c5cf3d Compare August 14, 2025 15:10
@webkit-commit-queue
Copy link
Collaborator

Committed 298681@main (2c5cf3d): https://commits.webkit.org/298681@main

Reviewed commits have been landed. Closing PR #49270 and removing active labels.

@webkit-commit-queue webkit-commit-queue merged commit 2c5cf3d into WebKit:main Aug 14, 2025
@webkit-commit-queue webkit-commit-queue removed the unsafe-merge-queue Applied to send a pull request to merge-queue, but skip building and testing label Aug 14, 2025
@annevk annevk deleted the eng/Cookie-Store-API-add-branch-for-empty-string-path branch August 14, 2025 16:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

WebCore Misc. For miscellaneous bugs in the WebCore framework (and not JavaScriptCore or WebKit).

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants