[PHP-DEV] [VOTE] Same Site Cookie RFC

LS,

Just now, I opened the RFC on implementing same site cookies in PHP,
https://wiki.php.net/rfc/same-site-cookie, for voting.

It consists of two questions, depending on the implementation you would
like to see of the feature. Both questions will affect the API of four
core functions: setcookie, setrawcookie, session_set_cookie_params and
session_get_cookie_params. The first three functions have a similar
function signature. The first implementation suggestion is to add an
additional argument to these three functions. The second implementation
suggestion is to allow an array of options in which all the cookie
options will be moved into. More details are to be found in the RFC.

Hopefully, the samesite cookie flag will become a feature of the PHP
language through this RFC!

Kind regards,
Frederik Bosch

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 25 August 2017 at 22:19, Frederik Bosch <[email protected]> wrote:
> LS,
>
> Just now, I opened the RFC on implementing same site cookies in PHP,
> https://wiki.php.net/rfc/same-site-cookie, for voting.

Please be explicit:

> Proposed PHP Version(s)
> next PHP 7.x


It's really late in the day for 7.2. Although people might still vote
for it, the RFC needs to be explicit about which version it is for.


cheers
Dan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi Dan,

While I agree on your statement that it is late for 7.2, I believe the
text is explicit enough. Since features for PHP 7.2 are frozen,
according to the rules this should go for the version thereafter.
However, if a release managers wants to pick up it and embed in 7.2, I
am not going to protest. Things considered, I see no reason to change
the sentence.

Best,
Frederik



On 26-08-17 00:18, Dan Ackroyd wrote:
> On 25 August 2017 at 22:19, Frederik Bosch <[email protected]> wrote:
>> LS,
>>
>> Just now, I opened the RFC on implementing same site cookies in PHP,
>> https://wiki.php.net/rfc/same-site-cookie, for voting.
> Please be explicit:
>
>> Proposed PHP Version(s)
>> next PHP 7.x
>
> It's really late in the day for 7.2. Although people might still vote
> for it, the RFC needs to be explicit about which version it is for.
>
>
> cheers
> Dan


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Fri, Aug 25, 2017 at 6:18 PM, Dan Ackroyd <[email protected]> wrote:
> On 25 August 2017 at 22:19, Frederik Bosch <[email protected]> wrote:
>> LS,
>>
>> Just now, I opened the RFC on implementing same site cookies in PHP,
>> https://wiki.php.net/rfc/same-site-cookie, for voting.
>
> Please be explicit:
>
>> Proposed PHP Version(s)
>> next PHP 7.x
>
>
> It's really late in the day for 7.2. Although people might still vote
> for it, the RFC needs to be explicit about which version it is for.
>
>
In my opinion it's too late for 7.2 especially as it contains an ABI
break which at best will be annoying for the folks helping us test.
The primary vote should be about 7.3 and if this wants to land on 7.2
there should be a separate vote for that.

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Le 26/08/2017 à 01:10, Sara Golemon a écrit :

> In my opinion it's too late for 7.2 especially as it contains an ABI
> break which at best will be annoying for the folks helping us test.
> The primary vote should be about 7.3 and if this wants to land on 7.2
> there should be a separate vote for that.

+1


BTW, choice 1 seems awfull but preserve BC

Perhaps choice 2 could be implemented in a BC way, allowing both proto

Ex for session_set_cookie_params

Parse arg 2 as an optional zval

if arg2 is an array
if argc > 2 error
else new proto, array of options
else old proto


Remi.

Hi Sara,

Thanks for clearing this. I have no intension to have it merged in 7.2
so I updated the RFC to specifically mention it is for 7.3. If other
people want to have it in 7.2, they can start a new RFC to make that happen.

Best,
Frederik



On 26-08-17 01:10, Sara Golemon wrote:
> On Fri, Aug 25, 2017 at 6:18 PM, Dan Ackroyd <[email protected]> wrote:
>> On 25 August 2017 at 22:19, Frederik Bosch <[email protected]> wrote:
>>> LS,
>>>
>>> Just now, I opened the RFC on implementing same site cookies in PHP,
>>> https://wiki.php.net/rfc/same-site-cookie, for voting.
>> Please be explicit:
>>
>>> Proposed PHP Version(s)
>>> next PHP 7.x
>>
>> It's really late in the day for 7.2. Although people might still vote
>> for it, the RFC needs to be explicit about which version it is for.
>>
>>
> In my opinion it's too late for 7.2 especially as it contains an ABI
> break which at best will be annoying for the folks helping us test.
> The primary vote should be about 7.3 and if this wants to land on 7.2
> there should be a separate vote for that.
>
> -Sara


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi Sara, hi Frederik,

Sounds good! Let's vote in getting it in first and then we can have a 2nd RFC (and vote) if it should land in 7.2

cu,
Lars

Sent from my electronic toy

> On 26. Aug 2017, at 17:34, Frederik Bosch <[email protected]> wrote:
>
> Hi Sara,
>
> Thanks for clearing this. I have no intension to have it merged in 7.2 so I updated the RFC to specifically mention it is for 7.3. If other people want to have it in 7.2, they can start a new RFC to make that happen.
>
> Best,
> Frederik
>
>
>
>> On 26-08-17 01:10, Sara Golemon wrote:
>>> On Fri, Aug 25, 2017 at 6:18 PM, Dan Ackroyd <[email protected]> wrote:
>>>> On 25 August 2017 at 22:19, Frederik Bosch <[email protected]> wrote:
>>>> LS,
>>>>
>>>> Just now, I opened the RFC on implementing same site cookies in PHP,
>>>> https://wiki.php.net/rfc/same-site-cookie, for voting.
>>> Please be explicit:
>>>
>>>> Proposed PHP Version(s)
>>>> next PHP 7.x
>>>
>>> It's really late in the day for 7.2. Although people might still vote
>>> for it, the RFC needs to be explicit about which version it is for.
>>>
>>>
>> In my opinion it's too late for 7.2 especially as it contains an ABI
>> break which at best will be annoying for the folks helping us test.
>> The primary vote should be about 7.3 and if this wants to land on 7.2
>> there should be a separate vote for that.
>>
>> -Sara
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi,

Frederik Bosch wrote:
> LS,
>
> Just now, I opened the RFC on implementing same site cookies in PHP,
> https://wiki.php.net/rfc/same-site-cookie, for voting.


Correct me if I'm wrong, but wasn't the RFC only put to internals a week
ago? That's not a long enough discussion period before opening voting,
https://wiki.php.net/rfc/howto says it should be at least 2 weeks.

Regards.
--
Andrea Faulds
https://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Monday, August 28, 2017 4:24 AM Andrea Faulds wrote:

> Correct me if I'm wrong, but wasn't the RFC only put to internals a week
> ago? That's not a long enough discussion period before opening voting,
> https://wiki.php.net/rfc/howto says it should be at least 2 weeks.

The current RFC was put to internals on July 24, over a month ago
(in the "[RFC] samesite cookie implementation" thread).

Theodore Brown
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Sun, Aug 27, 2017 at 5:54 AM, Lars Strojny <[email protected]> wrote:
> Sounds good! Let's vote in getting it in first and then we can have a 2nd RFC (and vote) if it should land in 7.2
>
Mmmm, not quite. IF you want to aim for 7.2, do it now in the same
vote. Back porting is sub-optimal and there's not a rush to land it
on 7.3. The time sensitive part is 7.2.

FTR, I'll be voting "No" on a 7.2, and I've already submitted my yes
vote for 7.3 (options array variant).

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi,

On Mon, Aug 28, 2017 at 6:04 PM, Sara Golemon <[email protected]> wrote:
> On Sun, Aug 27, 2017 at 5:54 AM, Lars Strojny <[email protected]> wrote:
>> Sounds good! Let's vote in getting it in first and then we can have a 2nd RFC (and vote) if it should land in 7.2
>>
> Mmmm, not quite. IF you want to aim for 7.2, do it now in the same
> vote. Back porting is sub-optimal and there's not a rush to land it
> on 7.3. The time sensitive part is 7.2.
>

I second this.

In fact, there was a competing idea/RFC when the discussion started,
but the author of this one insisted that there's no time to wait for
that. To me, it doesn't make sense to rush this (compared to
alternative ideas) if it doesn't get into 7.2.

Cheers,
Andrey.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi Andrey,

While I agree on your statement that back-porting is suboptimal, I do
not agree on the fact that I said that there was no time to wait. I
submitted the RFC, awaited the opinions, changed the document according
to the different viewpoints and I link to the other RFC from this RFC. I
do not want to 'push' this through. I think we know the opinions, so it
is time to vote. If both suggestions from this RFC don't make, then
people can go for other solutions.

Best,
Frederik



On 28-08-17 17:23, Andrey Andreev wrote:
> Hi,
>
> On Mon, Aug 28, 2017 at 6:04 PM, Sara Golemon <[email protected]> wrote:
>> On Sun, Aug 27, 2017 at 5:54 AM, Lars Strojny <[email protected]> wrote:
>>> Sounds good! Let's vote in getting it in first and then we can have a 2nd RFC (and vote) if it should land in 7.2
>>>
>> Mmmm, not quite. IF you want to aim for 7.2, do it now in the same
>> vote. Back porting is sub-optimal and there's not a rush to land it
>> on 7.3. The time sensitive part is 7.2.
>>
> I second this.
>
> In fact, there was a competing idea/RFC when the discussion started,
> but the author of this one insisted that there's no time to wait for
> that. To me, it doesn't make sense to rush this (compared to
> alternative ideas) if it doesn't get into 7.2.
>
> Cheers,
> Andrey.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi Frederik,

On Mon, Aug 28, 2017 at 6:34 PM, Frederik Bosch | Genkgo
<[email protected]> wrote:
> Hi Andrey,
>
> While I agree on your statement that back-porting is suboptimal, I do not
> agree on the fact that I said that there was no time to wait. I submitted
> the RFC, awaited the opinions, changed the document according to the
> different viewpoints and I link to the other RFC from this RFC. I do not
> want to 'push' this through. I think we know the opinions, so it is time to
> vote. If both suggestions from this RFC don't make, then people can go for
> other solutions.
>

You did wait for, and adjust according to suggestions, I'm not questioning that.

I was referring to this message: https://externals.io/message/99884#99893

If you want this to land in 7.2 (i.e. not "take a while before we see
samesite cookie implemented"), then there really is no time to wait.
I'm not being negative here ... I'm using this as an argument to make
the vote for 7.2 now.
Otherwise, we have an entire year to polish all the details in time for 7.3.

Cheers,
Andrey.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi Andrey,

Little misunderstanding then. I agree we can better have this PHP 7.3
and take some time for it. Current votes also suggest that we should go
for the array argument implementation. Since there is only a PR for the
extra argument implementation, it will also take time to have the PR for
the array argument implementation ready. Taken that into account, we
should not want this in 7.2.

Best,
Frederik



On 28-08-17 17:58, Andrey Andreev wrote:
> Hi Frederik,
>
> On Mon, Aug 28, 2017 at 6:34 PM, Frederik Bosch | Genkgo
> <[email protected]> wrote:
>> Hi Andrey,
>>
>> While I agree on your statement that back-porting is suboptimal, I do not
>> agree on the fact that I said that there was no time to wait. I submitted
>> the RFC, awaited the opinions, changed the document according to the
>> different viewpoints and I link to the other RFC from this RFC. I do not
>> want to 'push' this through. I think we know the opinions, so it is time to
>> vote. If both suggestions from this RFC don't make, then people can go for
>> other solutions.
>>
> You did wait for, and adjust according to suggestions, I'm not questioning that.
>
> I was referring to this message: https://externals.io/message/99884#99893
>
> If you want this to land in 7.2 (i.e. not "take a while before we see
> samesite cookie implemented"), then there really is no time to wait.
> I'm not being negative here ... I'm using this as an argument to make
> the vote for 7.2 now.
> Otherwise, we have an entire year to polish all the details in time for 7.3.
>
> Cheers,
> Andrey.

--


Frederik Bosch


Partner

Genkgo logo
Mail: f.bosch@genkgo.nl <mailto:[email protected]>
Web: support.genkgo.com https://support.genkgo.com

Entrada 123
Amsterdam
+31 208 943 931

Genkgo B.V. staat geregistreerd bij de Kamer van Koophandel onder nummer
56501153

On Mon, Aug 28, 2017 at 12:10 PM, Frederik Bosch | Genkgo <[email protected]
> wrote:

> Little misunderstanding then. I agree we can better have this PHP 7.3 and
> take some time for it. Current votes also suggest that we should go for the
> array argument implementation. Since there is only a PR for the extra
> argument implementation, it will also take time to have the PR for the
> array argument implementation ready. Taken that into account, we should not
> want this in 7.2.
>
Indeed, yes. Assuming the votes continue on this sharp lean towards the
array option, we should just forget all notions of trying to sneak this
into 7.2.

Direct calls in 7.2 and earlier can easily fall back on calling
header('Set-Cookie: ...'); manually, while sessions support is slightly
more complex, but still doable from userspace. I expect if need is deemed
high for this, a drop-in composer package can do 90% of the work
automatically.

-Sara

Hi!

> additional argument to these three functions. The second implementation
> suggestion is to allow an array of options in which all the cookie
> options will be moved into. More details are to be found in the RFC.

Something not clear to me on the second one - why lifetime/expiration is
a separate parameter while all others are part of $options?

--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi Stanislav,

My reasoning for this is as follows.

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.

Best,
Frederik




On 28-08-17 21:06, Stanislav Malyshev wrote:
> Hi!
>
>> additional argument to these three functions. The second implementation
>> suggestion is to allow an array of options in which all the cookie
>> options will be moved into. More details are to be found in the RFC.
> Something not clear to me on the second one - why lifetime/expiration is
> a separate parameter while all others are part of $options?
>

Hi Sara, hi Frederik,



Thinking more about this I came to change my vote (and for that reason I’ll take back the suggestion to include it into 7.2):


The array API is the better API and allows for healthier future growth so we should pursue that option
There is a (very ugly) workaround to set a same site policy by misusing the “session.cookie_path” or “session.cookie_domain” setting (e.g. set it to “/; SameSite=Strict”, you are welcome, Internet).


cu,

Lars





On 28.08.17, 18:20, "Sara Golemon" <[email protected] on behalf of [email protected]> wrote:



On Mon, Aug 28, 2017 at 12:10 PM, Frederik Bosch | Genkgo <[email protected]> wrote:

Little misunderstanding then. I agree we can better have this PHP 7.3 and take some time for it. Current votes also suggest that we should go for the array argument implementation. Since there is only a PR for the extra argument implementation, it will also take time to have the PR for the array argument implementation ready. Taken that into account, we should not want this in 7.2.

Indeed, yes. Assuming the votes continue on this sharp lean towards the array option, we should just forget all notions of trying to sneak this into 7.2.



Direct calls in 7.2 and earlier can easily fall back on calling header('Set-Cookie: ...'); manually, while sessions support is slightly more complex, but still doable from userspace. I expect if need is deemed high for this, a drop-in composer package can do 90% of the work automatically.

-Sara

Hi Theodore,

Theodore Brown wrote:
> On Monday, August 28, 2017 4:24 AM Andrea Faulds wrote:
>
>> Correct me if I'm wrong, but wasn't the RFC only put to internals a week
>> ago? That's not a long enough discussion period before opening voting,
>> https://wiki.php.net/rfc/howto says it should be at least 2 weeks.
>
> The current RFC was put to internals on July 24, over a month ago
> (in the "[RFC] samesite cookie implementation" thread).

Ah, you're right of course, my apologies to everyone. I was quite tired
yesterday and I think I misread “2017-07-17” as “2017-08-17”.

--
Andrea Faulds
https://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

There are no voting dates in the RFC, but it's open for over a month now.

I guess it can be closed.

Regards, Niklas

2017-08-25 23:19 GMT+02:00 Frederik Bosch <[email protected]>:

> LS,
>
> Just now, I opened the RFC on implementing same site cookies in PHP,
> https://wiki.php.net/rfc/same-site-cookie, for voting.
>
> It consists of two questions, depending on the implementation you would
> like to see of the feature. Both questions will affect the API of four core
> functions: setcookie, setrawcookie, session_set_cookie_params and
> session_get_cookie_params. The first three functions have a similar
> function signature. The first implementation suggestion is to add an
> additional argument to these three functions. The second implementation
> suggestion is to allow an array of options in which all the cookie options
> will be moved into. More details are to be found in the RFC.
>
> Hopefully, the samesite cookie flag will become a feature of the PHP
> language through this RFC!
>
> Kind regards,
> Frederik Bosch
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Hi Niklas,

Sorry for the delay. I have my mind on totally different things these
days. Closed the voting and moved it to accepted. Thanks everyone for
voting! Now, let's implement this RFC!

Best regards,
Frederik



On 08-10-17 09:46, Niklas Keller wrote:
> There are no voting dates in the RFC, but it's open for over a month now.
>
> I guess it can be closed.
>
> Regards, Niklas
>
> 2017-08-25 23:19 GMT+02:00 Frederik Bosch <[email protected]
> <mailto:[email protected]>>:
>
> LS,
>
> Just now, I opened the RFC on implementing same site cookies in
> PHP, https://wiki.php.net/rfc/same-site-cookie
> https://wiki.php.net/rfc/same-site-cookie, for voting.
>
> It consists of two questions, depending on the implementation you
> would like to see of the feature. Both questions will affect the
> API of four core functions: setcookie, setrawcookie,
> session_set_cookie_params and session_get_cookie_params. The first
> three functions have a similar function signature. The first
> implementation suggestion is to add an additional argument to
> these three functions. The second implementation suggestion is to
> allow an array of options in which all the cookie options will be
> moved into. More details are to be found in the RFC.
>
> Hopefully, the samesite cookie flag will become a feature of the
> PHP language through this RFC!
>
> Kind regards,
> Frederik Bosch
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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 <[email protected]> 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

On 18.07.2018 at 23:00, Pedro Magalhães wrote:

> 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 <[email protected]> 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.
>
> 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?

Personally, I'd even prefer this, but that's not what was voted upon, so
I'm not sure if it's okay. Anyhow, the implementation is available as
https://github.com/php/php-src/pull/3398. Thanks, Pedro!

> 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?

I'd prefer “expire_s_”, but I'm okay with “lifetime”.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Sat, Jul 21, 2018 at 12:11 PM Christoph M. Becker <[email protected]>
wrote:

> Personally, I'd even prefer this, but that's not what was voted upon, so
> I'm not sure if it's okay. Anyhow, the implementation is available as
> https://github.com/php/php-src/pull/3398. Thanks, Pedro!
>

I personally believe that the intent of the vote is to have this feature
and to have it included as an alternative array of parameters. I don't mean
to step on anyone's toes with the proposed implementation, but given that
the RFC doesn't define the array of options I think most people didn't
notice this design choice and/or ultimately just wanted this feature
accepted.


> > 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?
>
> I'd prefer “expire_s_”, but I'm okay with “lifetime”.
>

Although I had suggested using the same key for all functions, when I
started the implementation I realized they have different meanings. For
session_get_cookie_params, lifetime is a relative amount of seconds, but
for setcookie and setrawcookie expire is an absolute timestamp. So I kept
that distinction.
About your suggestion, I looked again, and in fact, the only place where
the parameter is called expire is in the docs. Internally (ie. Reflection)
it is called expires. Given this and the fact that it is what actually is
used in the cookie header, I've changed the key to "expires".

Regards,
Pedro

Hi,

On Thu, Jul 19, 2018 at 12:00 AM, Pedro Magalhães <[email protected]> wrote:
>
> With this being said, would anyone oppose an implementation where all the
> options (including lifetime) are included in the array parameter?
>

Yes.

All other "options" are actual *cookie attribute* names, as defined by
the various IETF RFCs, while "lifetime" is just a convenient name used
by PHP. It doesn't correspond to a particular attribute, but instead
the values for the Expires and Max-Age attributes are derived from it.
I believe during discussion I insisted that the parameter be called
"attributes", for this very reason.
On another note, I also wanted that pretty much any key/value pair to
be accepted instead of raising an error, for forward compatibility.

Unfortunately, neither of these 2 points I raised were addressed, but
it also looked like the author abandoned the RFC mid-vote as he agreed
that targeting 7.2 at the time wasn't a good idea, only he didn't
actually close the vote. So ... I'm not even sure of the status of
this RFC?

Cheers,
Andrey.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Sat, Jul 21, 2018 at 11:26 PM Andrey Andreev <[email protected]> wrote:

> Yes.
>
> All other "options" are actual *cookie attribute* names, as defined by
> the various IETF RFCs, while "lifetime" is just a convenient name used
> by PHP. It doesn't correspond to a particular attribute, but instead
> the values for the Expires and Max-Age attributes are derived from it.
> I believe during discussion I insisted that the parameter be called
> "attributes", for this very reason.
>

Hi,

While I do understand your reasoning, I find it extremely unfriendly to the
user of the function to ask for one parameter separate from all the others
for that reason alone.
Also, keep in mind that all this function does is set the
`session.cookie_*` ini entries. So all parameters are treated equally.


> On another note, I also wanted that pretty much any key/value pair to
> be accepted instead of raising an error, for forward compatibility.
>

I really believe that the user spotting errors like `['expries' => time() +
3600]` faster is more valuable than FC.

Regards,
Pedro

On Sun, Jul 22, 2018 at 1:21 AM, Pedro Magalhães <[email protected]> wrote:

> On Sat, Jul 21, 2018 at 11:26 PM Andrey Andreev <[email protected]> wrote:
>
> > Yes.
> >
> > All other "options" are actual *cookie attribute* names, as defined by
> > the various IETF RFCs, while "lifetime" is just a convenient name used
> > by PHP. It doesn't correspond to a particular attribute, but instead
> > the values for the Expires and Max-Age attributes are derived from it.
> > I believe during discussion I insisted that the parameter be called
> > "attributes", for this very reason.
> >
>
> Hi,
>
> While I do understand your reasoning, I find it extremely unfriendly to the
> user of the function to ask for one parameter separate from all the others
> for that reason alone.
> Also, keep in mind that all this function does is set the
> `session.cookie_*` ini entries. So all parameters are treated equally.
>

To add to this, session_get_cookie_params() already returns all parameters
including "lifetime" in one array. It would be very weird if there was an
asymmetry between session_get_cookie_params() and
session_set_cookie_params().

Furthermore, the way I have seen session_set_cookie_params() used, it has
pretty much always been in conjunction with a prior
session_get_cookie_params() call to get the current values and then only
one (or some) of them being adjusted. It makes more sense to write

$params = session_get_cookie_params();
// Change $params here
session_set_cookie_params($params);

than having to treat just the $params["lifetime"] case specially.

Nikita

> On another note, I also wanted that pretty much any key/value pair to
> > be accepted instead of raising an error, for forward compatibility.
> >
>
> I really believe that the user spotting errors like `['expries' => time() +
> 3600]` faster is more valuable than FC.
>
> Regards,
> Pedro
>

Hi,

On Sun, Jul 22, 2018 at 2:21 AM, Pedro Magalhães <[email protected]> wrote:
> On Sat, Jul 21, 2018 at 11:26 PM Andrey Andreev <[email protected]> wrote:
>>
>> Yes.
>>
>> All other "options" are actual *cookie attribute* names, as defined by
>> the various IETF RFCs, while "lifetime" is just a convenient name used
>> by PHP. It doesn't correspond to a particular attribute, but instead
>> the values for the Expires and Max-Age attributes are derived from it.
>> I believe during discussion I insisted that the parameter be called
>> "attributes", for this very reason.
>
>
> Hi,
>
> While I do understand your reasoning, I find it extremely unfriendly to the
> user of the function to ask for one parameter separate from all the others
> for that reason alone.
> Also, keep in mind that all this function does is set the `session.cookie_*`
> ini entries. So all parameters are treated equally.
>

Ok, I can see how it can be inconvenient for
session_set_cookie_params(), though calling it "extremely" unfriendly
is some exaggeration IMO. But while I didn't quote that part of your
message, you did also suggest to apply the same decision to other
functions and so I am talking about all of them.

I'd be ok with this for session_set_cookie_params() alone, but not for
set[raw]cookie().

>>
>> On another note, I also wanted that pretty much any key/value pair to
>> be accepted instead of raising an error, for forward compatibility.
>
>
> I really believe that the user spotting errors like `['expries' => time() +
> 3600]` faster is more valuable than FC.
>

Honestly, the fact that you chose "expires" for this particular
example IMO only makes a stronger case for why it needs to be
separated. :)

Cheers,
Andrey.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Am So., 22. Juli 2018 um 14:16 Uhr schrieb Andrey Andreev <[email protected]>:
>
> Hi,
>
> On Sun, Jul 22, 2018 at 2:21 AM, Pedro Magalhães <[email protected]> wrote:
> > On Sat, Jul 21, 2018 at 11:26 PM Andrey Andreev <[email protected]> wrote:
> >>
> >> Yes.
> >>
> >> All other "options" are actual *cookie attribute* names, as defined by
> >> the various IETF RFCs, while "lifetime" is just a convenient name used
> >> by PHP. It doesn't correspond to a particular attribute, but instead
> >> the values for the Expires and Max-Age attributes are derived from it.
> >> I believe during discussion I insisted that the parameter be called
> >> "attributes", for this very reason.
> >
> >
> > Hi,
> >
> > While I do understand your reasoning, I find it extremely unfriendly to the
> > user of the function to ask for one parameter separate from all the others
> > for that reason alone.
> > Also, keep in mind that all this function does is set the `session.cookie_*`
> > ini entries. So all parameters are treated equally.
> >
>
> Ok, I can see how it can be inconvenient for
> session_set_cookie_params(), though calling it "extremely" unfriendly
> is some exaggeration IMO. But while I didn't quote that part of your
> message, you did also suggest to apply the same decision to other
> functions and so I am talking about all of them.
>
> I'd be ok with this for session_set_cookie_params() alone, but not for
> set[raw]cookie().
>
> >>
> >> On another note, I also wanted that pretty much any key/value pair to
> >> be accepted instead of raising an error, for forward compatibility.
> >
> >
> > I really believe that the user spotting errors like `['expries' => time() +
> > 3600]` faster is more valuable than FC.
> >
>
> Honestly, the fact that you chose "expires" for this particular
> example IMO only makes a stronger case for why it needs to be
> separated. :)

It'd be great to use an OO approach instead of "magic" array keys,
e.g. like this:
https://github.com/amphp/http/blob/9c0ba2f2ebfae482b3ad7a0475eb3d1f74d87949/src/Cookie/CookieAttributes.php

Regards, Niklas

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Sun, Jul 22, 2018 at 1:16 PM Andrey Andreev <[email protected]> wrote:

> Ok, I can see how it can be inconvenient for
> session_set_cookie_params(), though calling it "extremely" unfriendly
> is some exaggeration IMO.


Hi,

Right, I may have been a bit overly dramatic. :)


> But while I didn't quote that part of your
> message, you did also suggest to apply the same decision to other
> functions and so I am talking about all of them.
>
> I'd be ok with this for session_set_cookie_params() alone, but not for
> set[raw]cookie().
>

I thought your comment was about session_set_cookie_params only because
your reasoning about lifetime (as a relative amount of time) being a PHP
construct only makes sense there.
So I'm not sure why for set[raw]cookie the expires attribute would be
treated different from the others? Max-Age is derived from it, but the
value you pass to expires will be directly used in the cookie attribute
(although in a different datetime format). Some other attributes are also
not used verbatim. For instance, 'secure' being true or false also means
the `secure;` attribute being present or omitted.
Thinking again from the perspective of the user, I would find it annoying
to have the expires attribute separate from the others.

Regards,
Pedro