2016-10-20 11:57 GMT+02:00 Yasuo Ohgaki <yohg...@ohgaki.net>: > Hi Niklas, > > On Thu, Oct 20, 2016 at 6:01 PM, Niklas Keller <m...@kelunik.com> wrote: > > > > same here, it's not acceptable to limit header and restrict `set_cookie`. > > Just think about all those frameworks that would have to specialcase > setting > > headers now and have to use the cookie API then. > > > > If you want to protect the session cookie header, why not simply set it > > right before the first output? That'd make it also non-overrideable, but > > leaves header() intact. But I guess it's harder to implement. > > Although, I prefer to have completely separate API, we have to > implement vote result. So vote no for "Disabling 'Set-Cookie' for > header*()" vote option. >
I don't have a vote. But this breaks BC. It might remove surprisings when using sessions, but having header() not being able to set `set-cookie` headers adds new surprisings. > Regarding about delaying session cookie header, it is possible to use > output buffer to delay output so that session module can send HTTP > header at request shutdown. However, it will break almost all session > enabled applications that require immediate output. Therefore, it's > easy to implement, but not possible for this reason. I meant squeeze in right before output or on first flush() call. There must be a thing that sets a "already output" flag that prevents further headers. We could use that mechanism to buffer all headers and just send them out there and have a hook for the session module. Regards, Niklas > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
