New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 652627 link

Starred by 1 user
Status: Duplicate
Merged: issue 649416
Owner: ----
Closed: Oct 2016
Cc:
█ mkwst@chromium.org
█ jww@chromium.org
█ maksim.s...@intel.com
mark@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug-Regression



Sign in to add a comment

Cookies are non persistent on devices with 32 bit integer timestamps

Reported by land...@opera.com, Oct 4 2016 
Version: master
OS: Linux

What steps will reproduce the problem?
(1) Use a cookie line with "expires=Fri, 31 Dec 9999 23:59:59 GMT". I think this is a pretty common way of having never expires cookies.

The cookie will not be persistent after https://codereview.chromium.org/1988663002 landed on Linux platforms that has a time_t that is 32 bit signed integer.
Before that change a best effort was made to return the highest value representable by the platform but now there is null Time returned which makes the cookie non persistent.

Comment 1 by land...@opera.com, Oct 4 2016 

I pushed a review that has some kind of fix for this, mostly to demonstrate what goes wrong. I would actually prefer the original solution where a best effort was returned together with the added return value that allow you to check if the Time value conversion was successful.

Comment 2 by land...@opera.com, Oct 4 2016 

And here is that review: https://codereview.chromium.org/2392873002

Comment 3 by msramek@chromium.org, Oct 4 2016

Cc: jww@chromium.org mkwst@chromium.org

Comment 4 by mmenke@chromium.org, Oct 4 2016

Mergedinto: 649416
Status: Duplicate (was: Untriaged)
The original solution was bad in cases where there were security considerations (Cert timestamps, for instance)

Comment 5 by land...@opera.com, Oct 6 2016 

Yes, you should be really careful when using the unsuccessful result of course. Anyway, good that you are working on a solution. Thanks.
►

Sign in to add a comment