Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 9bf64b3a9b97a77e359d6d8c70cb4f934575fbf0
https://github.com/WebKit/WebKit/commit/9bf64b3a9b97a77e359d6d8c70cb4f934575fbf0
Author: Rupin Mittal <[email protected]>
Date: 2025-01-22 (Wed, 22 Jan 2025)
Changed paths:
M Source/WebCore/Modules/cookie-store/CookieStore.cpp
Log Message:
-----------
[Cookie Store API] Fix quick expiry issue by accounting for CFNetwork
flooring of cookie creation and expiration times
https://bugs.webkit.org/show_bug.cgi?id=286164
rdar://143088705
Reviewed by Sihui Liu.
If an event listener is registered, setting a cookie with a sub-1 second
expiry (like 300 milliseconds) should cause a change event to be fired.
Currently, it often wrongly fires as a deletion event.
The API uses WebCore::Cookies, which hold the creation and expiry times
in milliseconds. But setting the cookies with CFNetwork API means first
converting them into NSHTTPCookies, which hold these times in seconds.
CFNetwork then floors these times. This means the milliseconds are lost.
This is the cause of the problem.
Consider these two cases:
(1)
WebCore::Cookie creation time: 1024.22 milliseconds
WebCore::Cookie expiry time: 1324.22 milliseconds
Difference is 300 milliseconds --> (expiry > creation) This is a change event
Converting to an NSHTTPCookie means converting to seconds and then flooring:
Converting seconds gives us 1.02 and 1.32, then flooring gives us:
NSHTTPCookie creation time: 1.00 seconds
NSHTTPCookie expiry time: 1.00 seconds
Difference is 0 seconds --> (expiry <= creation) This is a deletion event
(WRONG)
(2)
WebCore::Cookie creation time: 1924.22 milliseconds
WebCore::Cookie expiry time: 2224.22 milliseconds
Difference is 300 milliseconds --> (expiry > creation) This is a change event
Converting to an NSHTTPCookie means converting to seconds and then flooring:
Converting seconds gives us 1.92 and 2.22, then flooring gives us:
NSHTTPCookie creation time: 1.00 seconds
NSHTTPCookie expiry time: 2.00 seconds
Difference is 1 seconds --> (expiry > creation) This is a change event (CORRECT)
So if the difference between the expiry and creation is less than 1 second,
flooring may reduce the difference to 0 seconds and cause the event to
incorrectly
fire as a deletion.
To fix this, if the expiry is greater than creation (expires in the future),
and the
conversion to an NSHTTPCookie (conversion to seconds and flooring) will make
the expiry
and creation equal, we add 1 second to the expiry time (we don't need it for
expiry
times in the past since a difference of 0 is considered deletion). This way,
after
flooring the difference will be 1 second. So the event will fire correctly.
Manual testing on the Cookie Store test site shows that this works as intended.
* Source/WebCore/Modules/cookie-store/CookieStore.cpp:
(WebCore::CookieStore::set):
Canonical link: https://commits.webkit.org/289245@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
