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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
