Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » setcookie() and Max-Age »

setcookie() and Max-Age

php.internals

Andi Gutmans

22 years ago
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

Christian Schneider

22 years ago
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

Andi Gutmans

22 years ago
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:

Rasmus Lerdorf

22 years ago
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 On Tue, 17 Aug 2004, Andi Gutmans wrote:

Derick Rethans

22 years ago
On Tue, 17 Aug 2004, Rasmus Lerdorf wrote:
> 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

Andi Gutmans

22 years ago
I think overloading the type is a good idea. Might even be best to use something which doesn't resemble a number for instance "Max-Age: 3600". We could just send that out in the header if it's a string (although it might leave room for typos). Any other ideas or sexier ways to do the overloading? Andi At 04:55 PM 8/17/2004 -0700, Rasmus Lerdorf wrote:

Rasmus Lerdorf

22 years ago
Perhaps it makes more sense to just give it an array there. I agree that "+3600" is not great either as I am sure someone will try to just pass +3600 without the quotes. How about this: setcookie('name',$value,array('Max-Age'=>3600, 'Comment'=>$comment, 'Path'=>'/'); So, in this overloaded form you just have 3 arguments and you put all your args in that 3rd array arg. RFC 2109 lists all the attributes possible. Version and Comment are the other two we don't currently have a way to send, so if we address Max-Age we should also add a way to send those other two. It even says the version field is required, but that must be a rather relaxed use of the term, 'required'. -Rasmus On Tue, 17 Aug 2004, Andi Gutmans wrote:

Sterling Hughes

22 years ago
+1 -Sterling On Tue, 17 Aug 2004 18:05:12 -0700 (PDT), Rasmus Lerdorf <rasmus@php.net> wrote:

Christian Schneider

22 years ago
Rasmus Lerdorf wrote:
> How about this: > setcookie('name',$value,array('Max-Age'=>3600, 'Comment'=>$comment, 'Path'=>'/');
One drawback is that people have to know about the cookie specifications, e.g. 'Max-Age': Is it case sensitive, does it have a dash between max and age, etc? That should at least be well-covered in the documentation to avoid having to look at the RFC. [ Side-note: You forgot one closing parens, a common mistake with named parameters, I recommend the patch we're using which allows to leave out array(): setcookie('name', $value, 'Max-Age'=>3600, 'Comment'=>$comment, 'Path'=>'/'); *Evil grin* ] - Chris

Derick Rethans

22 years ago
On Wed, 18 Aug 2004, Christian Schneider wrote:
> Rasmus Lerdorf wrote: > > How about this: > > setcookie('name',$value,array('Max-Age'=>3600, 'Comment'=>$comment, 'Path'=>'/'); > > One drawback is that people have to know about the cookie > specifications, e.g. 'Max-Age': Is it case sensitive, does it have a > dash between max and age, etc? That should at least be well-covered in > the documentation to avoid having to look at the RFC.
It can be made case-insensitive. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Andi Gutmans

22 years ago
Yeah I think that would work and it'd mean we probably wouldn't have to make any further API changes in the future if new fields arise (famous last words). At 06:05 PM 8/17/2004 -0700, Rasmus Lerdorf wrote: