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. As you mention, custom 'Set-Cookie' header is for advanced users. Those people wouldn't have problems with new API. 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.) Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
