rfc:cookie_max-age
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| rfc:cookie_max-age [2012/12/28 03:38] – [Request for Comments: Cookie Max-Age attribute] Bumped version number narf | rfc:cookie_max-age [2017/09/22 13:28] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 2: | Line 2: | ||
| * Version: 1.1 | * Version: 1.1 | ||
| * Date: 2012-12-28 | * Date: 2012-12-28 | ||
| - | * Author: Andrey Andreev <narf@bofh.bg> | + | * Author: Andrey Andreev <narf@devilix.net> |
| - | * Status: | + | * Status: |
| * First Published at: http:// | * First Published at: http:// | ||
| 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 | + | 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 |
| 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.1356665896.txt.gz · Last modified: 2017/09/22 13:28 (external edit)