# setcookie() and Max-Age - Thread: https://externals.io/message/12201 - Original archive: https://news-web.php.net/php.internals/12201 - Started by Andi Gutmans on 2004-08-17T23:17:59+00:00 - Messages: 5 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #12201 — Andi Gutmans — 2004-08-17T23:17:59+00:00 URL: https://externals.io/message/12201#12201 Hey, There's a very interesting user contributed note for the `setcookie()` function (Follows in the end). I think it makes sense to support Max-Age because it fixes clock skew problems between the client and server. Not sure if an how this could be added to `setcookie()` because of the already rich amount of parameters it accepts. Would it make sense to have something like setcookie_max_age() or something similar? Andi add a note User Contributed Notes setcookie mr-yellow at mr-yellow dot com 15-Aug-2004 10:14 Sorry Secure not Secure=1.... Instead of setcookie it would be much safer to use the new better specs and send the following. A 1 hour cookie is as follows: header('Set-Cookie: TestCookie=something+from+somewhere; Max-Age=3600; Domain=.www.domain.com; Path=/; secure;'); To Delete a cookie set -1: header('Set-Cookie: TestCookie=something+from+somewhere; Max-Age=-1; Domain=.www.domain.com; Path=/; secure;'); -Ben --- ## #12203 — Christian Schneider — 2004-08-17T23:46:05+00:00 URL: https://externals.io/message/12201#12203 · In reply to: #12201 Andi Gutmans wrote: > Not sure if an how this could be added to `setcookie()` because of the > already rich amount of parameters it accepts. Would it make sense to > have something like setcookie_max_age() or something similar? I think we should overload the expire parameter. Somewhat ugly but transforms the function into what it really should look like. Adding another parameter or even function complicates the life of everyone in the future and since a IMHO doable way exists I'd say we should keep it simple. Proposal: expire < 1000000000 (Sun Sep 9 01:46:40 2001) uses Max-Age and allows up to 31 years of Max-Age. If properly documented this should be ok IMHO. If people are afraid that someone hardcoded something before Sun Sep 9 2001 in their source code then we could lower it to 100000000 (Sat Mar 3 09:46:40 1973, 3.1 years) but I'd prefer the previous value. My .02$, - Chris --- ## #12204 — Andi Gutmans — 2004-08-17T23:49:21+00:00 URL: https://externals.io/message/12201#12204 · In reply to: #12201 If I understand correctly, what you're saying is that we should always use Max-Age and just do the conversion ourselves? Andi At 01:46 AM 8/18/2004 +0200, Christian Schneider wrote: >Andi Gutmans wrote: > > […] > >I think we should overload the expire parameter. Somewhat ugly but >transforms the function into what it really should look like. Adding >another parameter or even function complicates the life of everyone in the >future and since a IMHO doable way exists I'd say we should keep it simple. > >Proposal: expire < 1000000000 (Sun Sep 9 01:46:40 2001) uses Max-Age and >allows up to 31 years of Max-Age. If properly documented this should be ok >IMHO. > >If people are afraid that someone hardcoded something before Sun Sep 9 >2001 in their source code then we could lower it to 100000000 (Sat Mar 3 >09:46:40 1973, 3.1 years) but I'd prefer the previous value. > >My .02$, >- Chris --- ## #12205 — Rasmus Lerdorf — 2004-08-17T23:55:58+00:00 URL: https://externals.io/message/12201#12205 · In reply to: #12204 No, I think he is saying use Max-Age if the expire is before Sep. 2001. ie. if the expire timestamp looks like a small value and not a timestamp, treat it like a max-age, otherwise if it looks big enough to be a real unix timestamp, make it a normal absolute expiry. While that is an idea that will probably work, it seems messy to me. Code with hardcoded expiries in the past that previously wouldn't cause any cookies to be sent will now suddenly start sending cookies. I think I would rather see a separate function, or perhaps overload it by type instead. As in, SetCookie("foo","bar","+3600"); The fact that it is a string that start with a + indicates a Max-Age instead of an integer timestamp. This way the separation is clear. -Rasmus > If I understand correctly, what you're saying is that we should always use > Max-Age and just do the conversion ourselves? > > Andi > > At 01:46 AM 8/18/2004 +0200, Christian Schneider wrote: > > […] --- ## #12212 — Derick Rethans — 2004-08-18T07:28:30+00:00 URL: https://externals.io/message/12201#12212 · In reply to: #12205 > While that is an idea that will probably work, it seems messy to me. Code > with hardcoded expiries in the past that previously wouldn't cause any > cookies to be sent will now suddenly start sending cookies. Right, I think that is a bad idea too. > I think I would rather see a separate function, or perhaps overload it by > type instead. As in, SetCookie("foo","bar","+3600"); PHP is typeless (you words :) so I don't like this either as +3600 is the same as "+3600" for most other functions. I'd suggest to either add another parameter or make a new function which accepts "cookie" options through an array. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org