Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78554
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.53 as permitted sender)
Message-ID: <545554F7.70906@gmail.com>
Date: Sat, 01 Nov 2014 21:47:35 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CABRjmp_2DzhrGGoknZvSZ6fM=okjz+Od+2t0TVrNarc2fRLWiA@mail.gmail.com> <CAHMUw2HVmJD9syo8Rbc1=bA5S3U9umS0_XHFzwzWsY9Ee7UneQ@mail.gmail.com> <CAL+t6cEfbd7KbB=EbhdqgLKG6tBURgj+Ls9Y62tjOHL1Y+r-SA@mail.gmail.com> <CAH-PCH7tDQCtmAbPNOF4ONkeSQz5wr89XJ81a0USmzCqKi=26g@mail.gmail.com> <CAGAGxbYuimpj+phbNXn_3e_17vpGEkes7Pn5jCh9j27uZoOT8Q@mail.gmail.com> <CABRjmp8rdVmCPCA5xdfgUirCKg=kF3NHXYK0xmPgOxS+4sKc9w@mail.gmail.com> <m33i7l$17q$1@ger.gmane.org>
In-Reply-To: <m33i7l$17q$1@ger.gmane.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] setcookie() minor BC break - fixes issue #67736
From: rowan.collins@gmail.com (Rowan Collins)

On 01/11/2014 21:10, Alexander Kurilo wrote:
>> 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. 

My first thought on seeing unsetcookie() as a name was that it will lead 
to a lot of confusion as to what it actually does; if you didn't know 
about this discussion, would you expect it to:

a) remove a Set-Cookie header which has been added to the current 
response (the actual behaviour required to avoid the behaviour that 
SHOULD NOT be done according to the RFC), leaving any cookie the remote 
UA has stored untouched?
b) add a Set-Cookie header to the response to expire an existing cookie 
the remote UA might have stored (a useful feature, but unrelated to this 
bug)?
c) replace any existing Set-Cookie header with that cookie name with one 
which instead expires that cookie (i.e. both a and b at the same time)?

What seems to actually be wanted is more like replace_cookie() - "I 
asked you to set this cookie earlier this page load, but actually set 
this one instead". Or, equivalently, some change to setcookie()'s 
parameter list to allow this behaviour, as others have suggested.

There is already a lot of confusion around the difference between the 
cookies in $_COOKIE and those set with setcookie() (i.e. that your new 
cookie won't show up in the superglobal until next request). The idea of 
removing something from the list of cookies which are queued to be set 
by this response is not something that's easy to explain clearly in that 
context, so I think the naming and documentation of any such feature 
needs to be approached very carefully.

Regards,

-- 
Rowan Collins
[IMSoP]