Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102964
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.221.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAJd4=YaJHQe0v6b9LfbO4tkrjCL18n7pa322vn2WWHBmK_rZRA@mail.gmail.com>
References: <a4189866-23ea-4dc5-12a4-a7fbad8e5601@genkgo.nl>
 <1abd260d-ebc4-a062-3381-72485946e8bc@gmail.com> <a55b37e3-268c-f8ab-6545-6cf7a4f537f0@genkgo.nl>
 <CAJd4=Ya67XaX3bwwQn20GUQqEvEVe8XEepRz9+of6h4t4fC_fg@mail.gmail.com>
 <CAPhkiZzSfwMd7TthF7jcWwY+JTnFyamyevnWDZZhGGF_qpEpKA@mail.gmail.com>
 <CAJd4=YZfMgJ7pLwUx_0GqdV+KMCGqYZFhQEDV_2KTMOKiRi6dA@mail.gmail.com>
 <CAPhkiZyHTy8m8N9f531GTMcNNhWO7Rj0U9vtMXzg3FhGyJQ0Vg@mail.gmail.com>
 <CAJd4=Yb-Njie8_f+83BtDcu=smxOGL3_5pGtCyu91z81oMja9Q@mail.gmail.com>
 <CAPhkiZzZ1PfXS+9eEJ_E8Uks28woxcTSf0wV6wj6WakHEH9nPw@mail.gmail.com> <CAJd4=YaJHQe0v6b9LfbO4tkrjCL18n7pa322vn2WWHBmK_rZRA@mail.gmail.com>
Date: Tue, 24 Jul 2018 21:05:40 +0300
Message-ID: <CAPhkiZxY9t4vU=nYSxqEoPB=kzfEE2Rbi+GeUdhXTJ8NpfAd+Q@mail.gmail.com>
To: =?UTF-8?Q?Pedro_Magalh=C3=A3es?= <mail@pmmaga.net>
Cc: "Frederik Bosch | Genkgo" <f.bosch@genkgo.nl>, Stanislav Malyshev <smalyshev@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Same Site Cookie RFC
From: narf@devilix.net (Andrey Andreev)

Hi,

On Tue, Jul 24, 2018 at 7:37 PM, Pedro Magalh=C3=A3es <mail@pmmaga.net> wro=
te:
> On Sun, Jul 22, 2018 at 6:54 PM Andrey Andreev <narf@devilix.net> wrote:
>>
>> Last, but certainly not least, we talk about $expires here only becase
>> that's how it's (currently) named in either documentation and/or
>> reflection. But for all intents and purposes it may as well be named
>> $fooBar and it wouldn't matter as long as it is a concrete parameter,
>> whereas an associative array key name is very important. Now I'd have
>> to remember if it actually is "lifetime", "expire" or "expires" ... or
>> is it "max-age"? Not only that, but if it is either "expires" or
>> "max-age", I would rightfully have reasons to believe that the
>> expected input should be match the actual Set-Cookie attribute instead
>> of a PHP-specific value.
>> That's very unintuitive and I believe we have a general consensus on
>> this list that array parameters are somewhat evil. You have to
>> remember that the only reason we're doing this here is to avoid
>> parameter creep with potential for infinity, and nothing else.
>
>
> Hi Andrey,
>
> Well, "expires" is what ends up in the cookie header itself so I think th=
at
> it's simple to remember. But I do understand your arguments on semantic
> purity and the fact that Max-Age is derived from it but I still believe t=
hat
> in this case, it's not worth the distinction. If there ever comes a new
> attribute that won't be used verbatim, what would we do? Leave it between
> $expires and the options array and break all existing code? Leave it to t=
he
> end of the signature to avoid the BC break but then we are left with
> something really awkward?
>

Look, I get it - you have your preferences and don't want to give up
on them. But now you're just speculating and aside from basically
saying "not a big deal", you haven't really addressed my arguments.

> Given that we understand each other but we just disagree on what is more
> important, I'd really like to hear someone else's opinion. If we are to g=
et
> something into 7.3 (which I believe we should due to
> https://github.com/php/php-src/pull/2613#issuecomment-401266510) and with
> the feature freeze in one week, we should reach an agreement on what to d=
o
> very soon.
>

Fair enough. I too would like to see more people involved in the discussion=
.

Although ... if the RFC is considered to be accepted (which I am still
not 100% sure if it should be, but that seems to be the case), then
technically we already have a decision made by vote. Again, I'm not
particularly happy with how it was handled, but we do have it.

Cheers,
Andrey.