Skip to content
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.

Sign up for GitHub

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

Update EXPIRES info with clock skew #37745

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Update EXPIRES info with clock skew #37745

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ffa14b0
Update EXPIRES info with clock skew
ericlaw1979 Jan 21, 2025
57655ac
Update files/en-us/web/http/headers/set-cookie/index.md
hamishwillee Jan 31, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions files/en-us/web/http/headers/set-cookie/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -102,6 +102,7 @@ Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnl
> Many web browsers have a _session restore_ feature that will save all tabs and restore them the next time the browser is used. Session cookies will also be restored, as if the browser was never closed.

When an `Expires` date is set, the deadline is relative to the _client_ the cookie is being set on, not the server.
However, the server's `Date` header will be used to compute the clock skew between the client and the server, and the `Expires` date will be adjusted accordingly.
Comment on lines 104 to +105
Copy link
Collaborator

Choose a reason for hiding this comment

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

Thanks very much @ericlaw1979

So the statements in these two lines seem a little at odds.

  • The first line indicates that the client will interpret the time according to its own clock. That makes sense, it gets a time value and treats it as relative to its own clock, because that's the clock it has.
  • Your addition (second line) indicates that the DATE header is used by the browser to adjust for clock skew.

To me, that sounds like the final meaning of EXPIRES is relative to the original server time - right?
That's all a bit confusing to a reader.

MDN documents the spec, which seems to just parse the date as it is (i.e. the first line): Let the expiry-time be the result of parsing the attribute-value as cookie-date

It makes sense to me that browsers would do adjust for skew, because the server is what knows when the cookie is stale, but we can't present it as "the word of the spec" if it isn't. Do you happen to know what Safari does, or have evidence of where in the spec the behaviour you are describing appears (I know you said not documented anywhere, so just looking for something I can use as evidence).

Depending on how you answer would probably use weasel words here like (if you think this is reasonable):

Suggested change
When an `Expires` date is set, the deadline is relative to the _client_ the cookie is being set on, not the server.
However, the server's `Date` header will be used to compute the clock skew between the client and the server, and the `Expires` date will be adjusted accordingly.
When an `Expires` date is set, the value is interpreted by the client as relative to its own internal clock, which may differ from that of the server (according to the specification).
In practice, many browsers use the value in the server's `Date` header to compute the clock skew, and adjust the value of the `Expires` date to match the time intended by the server.
This includes Firefox and Chromium browsers, and may include others.

Copy link
Author

@ericlaw1979 ericlaw1979 Jan 31, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

So the statements in these two lines seem a little at odds.

The behavior is indeed hard to describe.

  • When deciding whether to send or store a cookie, the deadline is compared to the clock of the client device.
  • However, that deadline, as expressed by the EXPIRES header, is subject to adjustment upon initial receipt, based on the skew between the clocks of the server and the client.

I don't know what Safari does; it's hard to test because my serverside frameworks (ASP, ASP.NET) do not allow control of the DATE header, so all of my testing is done using Fiddler, which I only have on Windows.


- `HttpOnly` {{optional_inline}}

Expand Down