Hi Yasuo,
> On 20 Oct 2016, at 15:10, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > > Hi Stephen, > > On Thu, Oct 20, 2016 at 4:48 PM, Stephen Reay <step...@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 > yohg...@ohgaki.net > Cheers Stephen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
