Re: [VOTE] Same Site Cookie RFC

From: Date: Sun, 22 Jul 2018 12:16:35 +0000
Subject: Re: [VOTE] Same Site Cookie RFC
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-102949@lists.php.net to get a copy of this message
Hi, On Sun, Jul 22, 2018 at 2:21 AM, Pedro Magalhães <mail@pmmaga.net> wrote: > On Sat, Jul 21, 2018 at 11:26 PM Andrey Andreev <narf@devilix.net> 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.

« previous php.internals (#102949) next »