Re: header() removes all header of the same name.
| From: | Stephen Reay | Date: | Thu, 20 Oct 2016 08:23:30 +0000 |
| Subject: | Re: header() removes all header of the same name. | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-96506@lists.php.net to get a copy of this message | ||
Hi Yasuo,
> On 20 Oct 2016, at 15:10, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
> Hi Stephen,
>
> On Thu, Oct 20, 2016 at 4:48 PM, Stephen Reay <stephen@bobs-bits.com> wrote:
>>
>> Just to make my earlier point of view crystal clear: As a purely userland party and someone
>> maintaining a PHP framework, I don’t think it’s acceptable to limit which headers
>> header()/header_remove() can operate on, particularly when the problem you’re trying to
>> ‘solve’ is simply incorrect use of the functions available. It *is* possible to achieve any
>> outcome desired with *correct* use of the header, session and cookie functions (and assuming the
>> $replace argument to header() works correctly).
>>
>> I still believe the way to solve this issue is with better information about usage, not by
>> removing existing functionality.
>>
>> So, please do *not* consider this to be an acceptable solution.
>
> The idea is to separate HTTP header handling functions.
>
> - header*() for any HTTP headers except 'Set-Cookie'
> - cookie*() for only 'Set-Cookie' header
>
> Developer does not lose anything.
The Developer *loses* what s/he has *now* - a fully functional header() function.
>
> As you mention, custom 'Set-Cookie' header is for advanced users.
> Those people wouldn't have problems with new API.
Those people shouldn’t have problems using header() properly.
>
> With this new API, we'll have standard confirming function names for
> cookie functions as a bonus, too. (I'm enthusiastic to clean up and
> have consistent function names as you might know.)
>
I don’t have a problem with improved function names. I have a problem with removing functionality
that is basically only ever going to be used by advanced developers, because it has *slightly* non
obvious behaviour that could be fixed by a simple documentation note.
Please understand: *no* “solution" where header() loses the ability to write any arbitrary
header will be acceptable in my opinion.
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>
Cheers
Stephen