Re: header() removes all header of the same name.

Hi Niklas, On Thu, Oct 20, 2016 at 9:21 PM, Niklas Keller <me@kelunik.com> wrote: > 2016-10-20 13:41 GMT+02:00 Yasuo Ohgaki <yohgaki@ohgaki.net>: >> >> Hi Stephen, >> >> On Thu, Oct 20, 2016 at 8:24 PM, Stephen Reay <php-lists@koalephant.com> >> wrote: >> > 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. >> >> My cookie*() functions proposal allows developers to remove header by >> cookie_remove() and can send any cookie header by cookie_custom(). >> Therefore, developers have full control if they have to. >> >> The only pain is that users may have to use cookie*() functions if we >> disallow header('Set-Cookie') which will be a vote option. If there is >> fully functional cookie*() functions, it will mitigate wrong >> header('Set-Cookie') usage regardless of the vote result, hopefully. > > > What about extensions to the set-cookie header? Take > SameSite as a > recent example. The setcookie API doesn't cover that. > Besides that, the > current setcookie API is awful, people just added more and more > parameters. > > Before we even discuss disallowing > header("set-cookie"), we should have a > sane cookie API, e.g. one that like setcookie($name, $value, > $flags). Sure I'll. I don't like it either. Array can be used for this. > > That's also the way we implemented it in Aerys > > (https://github.com/amphp/aerys/blob/9a7327f062aa678408dfe4f4c3c7f479db16f187/lib/Response.php#L49-L58). > It's a simple wrapper around addHeader to make life > easier, but it doesn't > restrict developers to call setHeader and replace all > set-cookie > headers. The function does it :) Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net