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
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
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:
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
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:
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
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