> 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
