Hi Yasuo,
As with Niklas, I have no vote, so my *only* option to prevent what I consider
to be a bad decision, is to post to this thread and hope that enough of those
who *do* have voting rights, reject the proposal.
I understand what you’re proposing. But honestly I don’t even agree with the
premise that there is a *problem* that needs to be fixed.
Did you know that if you manually set the Content-Length header to less than
the actual body length, many browsers (Safari, Chrome, and FF definitely) will
stop reading/processing the response at the length you specify?
So should we also prevent setting Content-Length via header() ?
Honestly I don’t understand how this is still a discussion. The developer
failed to set the $replace argument to false. At most I would expect this to
result in a documentation note warning about the use of header(‘Set-Cookie…’).
I appreciate you trying to make improvements, and I’d *definitely* be in favour
of the function naming cleanup you mentioned earlier, but all of this
“protected” headers and extra function calls, because someone forgot to type “,
false” seems ridiculous to me honestly.
Cheers
Stephen
> On 20 Oct 2016, at 18:41, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
>
> Hi Stephen,
>
> On Thu, Oct 20, 2016 at 8:24 PM, Stephen Reay <php-li...@koalephant.com>
> wrote:
>> The *only* solution that retains full control for the developer, is no
>> change. Any “magic” about “untouchable” cookie headers (e.g. forcing the
>> session cookie header after userland cookie headers) takes away options for
>> the developer.
>
> My cookie*() functions proposal allows developers to remove header by
> cookie_remove() and can send any cookie header by cookie_custom().
> Therefore, developers have full control if they have to.
>
> The only pain is that users may have to use cookie*() functions if we
> disallow header('Set-Cookie') which will be a vote option. If there is
> fully functional cookie*() functions, it will mitigate wrong
> header('Set-Cookie') usage regardless of the vote result, hopefully.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
