Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78553 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 13810 invoked from network); 1 Nov 2014 21:15:12 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Nov 2014 21:15:12 -0000 Authentication-Results: pb1.pair.com smtp.mail=php-php-dev@m.gmane.org; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=alex@kurilo.me; sender-id=unknown Received-SPF: pass (pb1.pair.com: domain m.gmane.org designates 80.91.229.3 as permitted sender) X-PHP-List-Original-Sender: php-php-dev@m.gmane.org X-Host-Fingerprint: 80.91.229.3 plane.gmane.org Received: from [80.91.229.3] ([80.91.229.3:35904] helo=plane.gmane.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 34/00-13276-C5D45545 for ; Sat, 01 Nov 2014 16:15:09 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Xkg0n-0006mm-8K for internals@lists.php.net; Sat, 01 Nov 2014 22:15:05 +0100 Received: from 63-234-66-2.dia.static.qwest.net ([63.234.66.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 Nov 2014 22:15:05 +0100 Received: from alex by 63-234-66-2.dia.static.qwest.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 Nov 2014 22:15:05 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: internals@lists.php.net Date: Sat, 01 Nov 2014 17:10:12 -0400 Lines: 59 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Gmane-NNTP-Posting-Host: 63-234-66-2.dia.static.qwest.net User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 In-Reply-To: Subject: Re: [PHP-DEV] setcookie() minor BC break - fixes issue #67736 From: alex@kurilo.me (Alexander Kurilo) On 01/11/14 13:09, Florian Margaine wrote: > Hi list, > > On the PR of the setcookie patch > to become compliant with the HTTP RFC, a valid use case for not throwing a > warning when running setcookie() twice with the same name: deleting cookies > (setcookie('name', '', ...);). It's thus been proposed to add an > unsetcookie() method. > > I'm not set on whether it's a good thing or not. I'm also not sure how to > handle this. > > There are some facts: > > - the current way does not follow the HTTP RFC. > - we cannot have the "last come last served" cookie because it's a BC break. > - the current functions cannot allow us to unset a cookie. > > What should be done? Trying to keep BC at a minimum by adding an > unsetcookie() method and add warnings? Try to detect the deletion of > cookies (empty value) and add warnings to keep even more BC? Just in case: I believe cookies are removed not by setting an empty value to them, but by setting their expiration date to a timestamp the past. > I'm unsure on what should be done and would like internals' opinion :-) > > On Tue, Sep 9, 2014 at 4:53 PM, Chris Wright wrote: > >> On 8 September 2014 09:09, Ferenc Kovacs wrote: >>> On Mon, Sep 8, 2014 at 9:15 AM, Sherif Ramadan >>> wrote: >>> >>>> Actually, we shouldn't be doing that all. We should simply just >> overwrite >>>> the header. It wouldn't make much sense to set two headers with the same >>>> cookie name when we can just overwrite it. >>>> >>>> >>>> >>> that would be a bigger BC break, and without a warning, those people >>> affected by the change will have a harder time figuring out what went >> wrong. >>> and as was discussed both in the PR and the bugreport the rfc discourages >>> but doesn't prohibit this behavior, so making it impossible for the >>> userland to do it would be a bit of an arbitrary restriction. >>> maybe we could do something like introducing a new $overwrite = true >> option >>> to the function signature, but setcookie already has 7 arguments, so >>> probably isn't a great idea. >> >> -- >>> Ferenc Kovács >>> @Tyr43l - http://tyrael.hu >> > > Regards, >