> How about delaying that warning until the headers are sent? I don't think there would be any benefit to that. The only possible scenarios are:
i) People sending duplicate headers by accident. When they see the error, they should fix their code, so the error goes away. ii) People who are deliberately sending duplicate headers (e.g. for a custom client that requires them). They will be suppressing the error and so it won't be seen anywhere. As I said in the PR, the current behaviour isn't a PHP bug, it's doing exactly what it was told to do by callee. Changing the behaviour of setcookie to 'guess' what the programmer really meant would definitely be wrong, and I'm not sure that giving a warning is all that helpful either. cheers Dan On 8 September 2014 07:50, Tjerk Meesters <tjerk.meest...@gmail.com> wrote: > Hi! > > > On Sat, Sep 6, 2014 at 5:38 AM, Florian Margaine <flor...@margaine.com> > wrote: > >> Hi, >> >> This is a minor BC break, but still a BC break, so worth discussing on this >> ML. >> >> When a second setcookie() is done with the same name, a warning is emitted, >> because the ietf rfc 6265 says it *should* only send one Set-Cookie header >> per name. >> >> This is fine when display_errors is set to off. When it's set to on, the >> warning prevents the header from being added because "headers already sent" >> (which is the minor BC break, as current PHP just sends 2 Set-Cookie >> headers with the same name). >> > > Yeah, it would prevent any header() or setcookie() following that warning > from taking place. > > How about delaying that warning until the headers are sent? > > >> >> So, should it be merged? What should be done to comply with the ietf rfc >> 6265? >> >> PR: https://github.com/php/php-src/pull/795/ >> PHP issue: https://bugs.php.net/bug.php?id=67736 >> >> Regards, >> >> *Florian Margaine* >> > > > > -- > -- > Tjerk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
