Hi Niklas, There is even a userland hook for the specific functionality you mention: header_register_callback().
But I would argue that no fix is necessary. If you as a developer call session_start(), and then later call header(‘Set-Cookie:…’) with replace left as true, I think it’s safe to assume you’re either doing it deliberately, or that you’ll go read the documentation on sessions and header() to discover the problem. (Or possibly file a bug which will be marked as not-a-bug and refer you to the documentation). 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. If *anything* the BC break being discussed should be to invert the default value for the $replace argument to header(). Cheers Stephen > On 20 Oct 2016, at 17:39, Niklas Keller <m...@kelunik.com> wrote: > > 2016-10-20 11:57 GMT+02:00 Yasuo Ohgaki <yohg...@ohgaki.net > <mailto:yohg...@ohgaki.net>>: > Hi Niklas, > > On Thu, Oct 20, 2016 at 6:01 PM, Niklas Keller <m...@kelunik.com > <mailto: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 <mailto:yohg...@ohgaki.net> > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > <http://www.php.net/unsub.php>
