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:
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
