Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:12205 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 9886 invoked by uid 1010); 17 Aug 2004 23:56:01 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 9769 invoked from network); 17 Aug 2004 23:56:00 -0000 Received: from unknown (HELO colo.lerdorf.com) (66.198.51.121) by pb1.pair.com with SMTP; 17 Aug 2004 23:56:00 -0000 Received: from rasmus2.corp.yahoo.com (rasmus2.corp.yahoo.com [207.126.233.18]) by colo.lerdorf.com (8.13.1/8.13.1/Debian-6) with ESMTP id i7HNtvqx020260; Tue, 17 Aug 2004 16:55:57 -0700 Date: Tue, 17 Aug 2004 16:55:58 -0700 (PDT) X-X-Sender: rasmus@t42p To: Andi Gutmans cc: Christian Schneider , internals@lists.php.net In-Reply-To: <5.1.0.14.2.20040817164902.04584dd0@127.0.0.1> Message-ID: References: <5.1.0.14.2.20040817161212.044edd50@127.0.0.1> <5.1.0.14.2.20040817161212.044edd50@127.0.0.1> <5.1.0.14.2.20040817164902.04584dd0@127.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [PHP-DEV] Re: setcookie() and Max-Age From: rasmus@php.net (Rasmus Lerdorf) 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 >