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)`.
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.
Regards, Niklas
