rfc:cookie_max-age

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Last revisionBoth sides next revision
rfc:cookie_max-age [2012/12/28 03:37] – Clarified the affected extensions and behavior + added examples narfrfc:cookie_max-age [2013/09/16 16:58] – Updated my email narf
Line 1: Line 1:
 ====== Request for Comments: Cookie Max-Age attribute ====== ====== Request for Comments: Cookie Max-Age attribute ======
-  * Version: 1.0+  * Version: 1.1
   * Date: 2012-12-28   * Date: 2012-12-28
-  * Author: Andrey Andreev <narf@bofh.bg+  * Author: Andrey Andreev <narf@devilix.net
-  * Status: Under Discussion+  * Status: Implemented
   * First Published at: http://wiki.php.net/rfc/cookie_max-age   * First Published at: http://wiki.php.net/rfc/cookie_max-age
  
Line 20: Line 20:
   - User agents always have correct time settings.   - User agents always have correct time settings.
  
-Since user agents will calculate the difference based on their own timestamp and the one that they receive, if any of the above two conditions isn't met, then we'll have a problem - the cookie will expire eiter earlier or later than expected. I can speak from experience, but I'm sure all of you would also understand and agree that this problem is very hard to debug in the rare cases where a client reports it.+Since user agents will calculate the difference based on their own timestamp and the one that they receive, if any of the above two conditions isn't met, then we'll have a problem - the cookie will expire either earlier or later than expected. I can speak from experience, but I'm sure all of you would also understand and agree that this problem is very hard to debug in the rare cases where a client reports it.
  
 Always sending a UTC-based timestamp should give us enough confidence to consider the first condition to always be satisfied. The second one however is never guaranteed and even though we can always blame the problem on a client-side configuration issue - why not just solve the problem once and for all, since a solution is available? Always sending a UTC-based timestamp should give us enough confidence to consider the first condition to always be satisfied. The second one however is never guaranteed and even though we can always blame the problem on a client-side configuration issue - why not just solve the problem once and for all, since a solution is available?
rfc/cookie_max-age.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1