Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78555
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
In-Reply-To: <545554F7.70906@gmail.com>
Date: Sat, 1 Nov 2014 22:24:35 +0000
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <581CB00C-59B7-4263-8533-D7DCB54C806E@ajf.me>
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> <545554F7.70906@gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] setcookie() minor BC break - fixes issue #67736
From: ajf@ajf.me (Andrea Faulds)


> On 1 Nov 2014, at 21:47, Rowan Collins <rowan.collins@gmail.com> =
wrote:
>=20
> 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.=20
>=20
> 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:
>=20
> 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)?

I=E2=80=99d expect it to do (a). But I can see your point with (b) and =
(c).

> 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.
>=20
> 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.

Perhaps it would be worth ditching any attempts to change setcookie() =
(just keep it around for backwards-compatibility), and to instead add a =
new function, function family, or indeed class for cookie handling. Some =
sort of sane API which would allow you to do a, b, or c, and make it =
clear which you wanted.

Thoughts? Any idea what such an API might look like?
--
Andrea Faulds
http://ajf.me/