Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102909
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain pmmaga.net designates 149.210.149.73 as permitted sender)
MIME-Version: 1.0
References: <a4189866-23ea-4dc5-12a4-a7fbad8e5601@genkgo.nl>
 <1abd260d-ebc4-a062-3381-72485946e8bc@gmail.com> <a55b37e3-268c-f8ab-6545-6cf7a4f537f0@genkgo.nl>
In-Reply-To: <a55b37e3-268c-f8ab-6545-6cf7a4f537f0@genkgo.nl>
Date: Wed, 18 Jul 2018 22:00:27 +0100
Message-ID: <CAJd4=Ya67XaX3bwwQn20GUQqEvEVe8XEepRz9+of6h4t4fC_fg@mail.gmail.com>
To: f.bosch@genkgo.nl
Cc: smalyshev@gmail.com, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000aad0e405714c5ab8"
Subject: Re: [PHP-DEV] [VOTE] Same Site Cookie RFC
From: mail@pmmaga.net (=?UTF-8?Q?Pedro_Magalh=C3=A3es?=)

--000000000000aad0e405714c5ab8
Content-Type: text/plain; charset="UTF-8"

On 28-08-17 21:06, Stanislav Malyshev wrote:

> Something not clear to me on the second one - why lifetime/expiration is
> a separate parameter while all others are part of $options?


On Mon, Aug 28, 2017 at 8:53 PM Frederik Bosch <f.bosch@genkgo.nl> wrote:

> 1. The session_set_cookie_params function requires a lifetime parameter
> at the moment.
>
> 2. To enforce that lifetime stays required I did not want to make it
> required within the optional array. That would make that optional array
> not optional anymore, and even have a required key. I don't think that
> is a good idea.
>
> 3. To prevent that the array of options is different between the three
> functions (session_set_cookie_params, setcookie, setrawcookie), I chose
> to exclude lifetime from the array of options and include it in the list
> of arguments.
>
> Hence, I chose a consistent and logical API over the three functions
> together rather than having logical ones per function. Hope it makes sense.
>

Hi all,

This reasoning doesn't make a lot of sense to me.
With regards to session_set_cookie_params, I believe that the only reason
why lifetime is required in that function is because calling it without
parameters doesn't have a purpose.
With an array of options (which keeps the first parameter mandatory), there
is no strong reason to make one of them required. An empty array or an
array without any valid key would still error.
If this is acceptable for that function, all the other functions can have
all the options in the array as that keeps the array consistent across them.

With this being said, would anyone oppose an implementation where all the
options (including lifetime) are included in the array parameter?

About the implementation, the array of options is never really defined in
the RFC. If we assume that it is identical to the proposed output
of session_get_cookie_params, the name of the first key should be lifetime.
However, for setcookie and setrawcookie, the documented parameter name is
expire. Would there be any issue if we would assume lifetime for the 4
functions?

Regards,
Pedro

--000000000000aad0e405714c5ab8--