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
