rfc:cookie_max-age

Differences

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

Link to this comparison view

Next revision		Previous revision
rfc:cookie_max-age [2012/12/28 02:16] – created narfrfc:cookie_max-age [2017/09/22 13:28] (current) – external edit 127.0.0.1
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 11: Line 11:
 ===== Introduction ===== ===== Introduction =====
  
-As already described by the title, this RFC proposes that //Max-Age// must be sent alongside the //Expires// attribute in //Set-Cookie// headers.+As already described by the title, this RFC proposes that **setcookie()**, **setrawcookie()** and **ext/session** must send the //Max-Age// attribute alongside //Expires// when a //Set-Cookie// header is created.
  
 ==== Why is it needed? ==== ==== Why is it needed? ====
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?
Line 38: Line 38:
  
 The above list makes it pretty clear that the behavior of any user agent that can't take advantage of //Max-Age// won't be affected. With that said, I believe that it is both safe and proper to send both //Expires// and //Max-Age// at the same time, as this will provide a proper fallback for any "legacy" browser that doesn't support //Max-Age//. The above list makes it pretty clear that the behavior of any user agent that can't take advantage of //Max-Age// won't be affected. With that said, I believe that it is both safe and proper to send both //Expires// and //Max-Age// at the same time, as this will provide a proper fallback for any "legacy" browser that doesn't support //Max-Age//.
 +
 +==== Logical behavior ====
 +
 +Since **setcookie()** and **setrawcookie()** accept a Unix timestamp - the TS delta will have to be calculated based on the provided timestamp, like this:
 +
 +''<max-age> = <provided unix timestamp> - <current time>''
 +
 +**ext/session** on the other hand will directly send the configured **session.cookie_lifetime** value, which is exactly the same - TS delta, in seconds.
 +
 +==== Possible BC effects ====
  
 No downside is expected, except the few more bytes being sent in HTTP headers. No downside is expected, except the few more bytes being sent in HTTP headers.
 +
 +===== Examples =====
 +
 +Assuming our current time is: Fri, 28-Dec-2012 03:00:00 GMT
 +
 +<code>
 +setcookie('name', 'value', 1356663605);
 +
 +// Old header:
 +// Set-Cookie: name=value; expires=Fri, 28-Dec-2012 03:00:05 GMT
 +
 +// New Header:
 +// Set-Cookie: name=value; Expires=Fri, 28-Dec-2012 03:00:05 GMT; Max-Age=5
 +</code>
 +
 +<code>
 +setrawcookie('name', 'value', 1356663595);
 +
 +// Old header:
 +// Set-Cookie: name=value; expires=Fri, 28-Dec-2012 02:59:55 GMT
 +
 +// New Header:
 +// Set-Cookie: name=value; Expires=Fri, 28-Dec-2012 02:59:55 GMT; Max-Age=-5
 +</code>
 +
 +<code>
 +session_name('PHPSESSID');
 +session_set_cookie_params(3600, '/', 'domain.tld');
 +session_start();
 +
 +// Old header:
 +// Set-Cookie: PHPSESSID=<random session id>; expires=Expires=Fri, 28-Dec-2012 04:00:00 GMT; path=/; domain=domain.tld
 +
 +// New header:
 +// Set-Cookie: PHPSESSID=<random session id>; Expires=Expires=Fri, 28-Dec-2012 04:00:00 GMT; Max-Age=3600; Path=/; Domain=domain.tld
 +</code>
  
 ===== Related links ===== ===== Related links =====
Line 52: Line 98:
 ===== Changelog ===== ===== Changelog =====
  
 +  * 2012-12-28: Updated with suggestions from the thread on PHP-Internals.
   * 2012-12-28: Initial version.   * 2012-12-28: Initial version.
rfc/cookie_max-age.1356661012.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools