Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100025
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.218.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <48.C0.18680.F6AE4795@pb1.pair.com>
References: <64.32.02884.7983D695@pb1.pair.com> <CAPhkiZy1Xo4mj758mtjcMGnX2PV0VsiHa9uN_Ka=1xiiXAx7Mg@mail.gmail.com>
 <86.8B.02884.8D93E695@pb1.pair.com> <CAPhkiZyuo+TtNNAd15hhQw07sA2QXaOD7xkHQ1Up7a3jT+FOsQ@mail.gmail.com>
 <48.C0.18680.F6AE4795@pb1.pair.com>
Date: Mon, 24 Jul 2017 11:00:51 +0300
Message-ID: <CAPhkiZyTnaHmv6nhdkh8crx1j1f_8+RvaYe+DGKSNHFPme8CaQ@mail.gmail.com>
To: Andreas Treichel <gmblar@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] http_cookie_set and http_cookie_remove
From: narf@devilix.net (Andrey Andreev)

Hello Andreas,

On Sun, Jul 23, 2017 at 9:26 PM, Andreas Treichel <gmblar@gmail.com> wrote:
> Hello Andrey,
>
>> That's what I was afraid of, and what I suggested be changed.
>>
>> If we had a similar, array-of-attributes API that did NOT ignore or
>> trigger warnings for unknown attributes, everybody using PHP would've
>> been able to use SameSite already.
>
>
> I think it is necessary to trigger a notice or warning for unknown options
> for troubleshooting.
>

I get that. However, that also means users have to wait for PHP
internals to discuss and vote on RFCs for each possible new cookie
attribute. Then wait for the release, and then the painfully slow
adoption rates.
And I'd also argue that the first thing one does while looking for
cookie-related issues is inspecting the response HTTP headers anyway,
so I don't think warnings would be that helpful.

Plus, this isn't something that can behave in unexpected ways; cookie
attributes have a clearly defined syntax.

>> On another note, I'd also move the 'expire' option to a separate
>> parameter and remove $options to $attributes.
>>
>> 'expire' is not a known cookie attribute; PHP uses it to calculate the
>> Expires and Max-Age attributes ...
>
>
> The "attribute" expires (not expire) existing in the header Set-Cookie.
>

That's what I said ... ?

I was suggesting that the array keys be reserved for actual
attributes, not arbitrary PHP options.

>> I liked your proposal, because it's a chance to have a shiny new API
>
>> that doesn't come with all the legacy stuff already built into
>> setcookie().
>
> I hope to meet your expectations.
>
>
>> But if we want an array-based setcookie() alternative without changing
>> anything else, we can just change setcookie() to accept arrays.
>
>
> No this is just the only the first step for additional extensions.
>

Care to elaborate?

You're not really addressing the concerns I'm raising, and now it
looks like you expect everybody to just trust you on this for the
promise of unknown goods in the future ... I'm sorry to say this, as I
want to help, but this is not a way to gather support.

Cheers,
Andrey.