Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78560
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basereality.com from 209.85.212.181 cause and error)
MIME-Version: 1.0
In-Reply-To: <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>
	<581CB00C-59B7-4263-8533-D7DCB54C806E@ajf.me>
Date: Sun, 2 Nov 2014 13:49:15 +0000
Message-ID: <CA+kxMuS_rBLOczPh27NED3xekSm0PMPs+DBUuZAnp8HxgwEDbw@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Rowan Collins <rowan.collins@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] setcookie() minor BC break - fixes issue #67736
From: danack@basereality.com (Dan Ackroyd)

Andrea wrote:
>Perhaps it would be worth ditching any attempts to change setcookie() (jus=
t keep it around for backwards-compatibility), and to instead add a new fun=
ction, function family, or indeed class for cookie handling.
>
>Thoughts? Any idea what such an API might look like?


I think this API could and should exist totally in userland.

Although it's nice that PHP ships with basic session support with it,
the exact details of session handling actually involve non-trivial
business logic

* What happens when the users IP address changes?
* What happens when a user tries to use session ID that has been
invalidated through session regeneration 2 seconds ago, 30 seconds.
* What rules should be applied to check the session integrity e.g.
user-agent checks.

All of the above can be done 'trivially' in userland. There is
absolutely no need to attempt to put the functionality for this in
core.

cheers
Dan


On 1 November 2014 22:24, Andrea Faulds <ajf@ajf.me> wrote:
>
>> On 1 Nov 2014, at 21:47, Rowan Collins <rowan.collins@gmail.com> wrote:
>>
>> 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 val=
ue 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 abou=
t this discussion, would you expect it to:
>>
>> a) remove a Set-Cookie header which has been added to the current respon=
se (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 un=
touched?
>> 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 bu=
g)?
>> 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 aske=
d 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 co=
okies 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 resp=
onse 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 approach=
ed very carefully.
>
> Perhaps it would be worth ditching any attempts to change setcookie() (ju=
st keep it around for backwards-compatibility), and to instead add a new fu=
nction, 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 yo=
u wanted.
>
> Thoughts? Any idea what such an API might look like?
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>