Hi Niklas, On Thu, Oct 20, 2016 at 9:21 PM, Niklas Keller <m...@kelunik.com> wrote: > 2016-10-20 13:41 GMT+02:00 Yasuo Ohgaki <yohg...@ohgaki.net>: >> >> Hi Stephen, >> >> On Thu, Oct 20, 2016 at 8:24 PM, Stephen Reay <php-li...@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 yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php