Andrea wrote: >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. > >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 <a...@ajf.me> wrote: > >> On 1 Nov 2014, at 21:47, Rowan Collins <rowan.coll...@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 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)? > > I’d 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. >> >> 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/ > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
