Re: [VOTE] Same Site Cookie RFC

On Tue, Jul 24, 2018 at 11:37 AM Pedro Magalhães <mail@pmmaga.net> wrote: > Well, "expires" is what ends up in the cookie header itself so I think > that 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 that 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 the end of the signature to avoid the BC break but > then we are left with something really awkward? > > 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 > get 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 do very soon. Have you investigated the way other languages/libraries handle this? I developed the es-cookie module (https://github.com/theodorejb/es-cookie), which shares the basic API of the very popular js-cookie library. Both libraries have a set function with name, value, and options parameters. expires is one of the properties that can be set in the options object (along with path, domain, secure, and sameSite). The expires property can be a number or a Date instance. I also looked at the other most popular npm packages for cookie handling (universal-cookie, browser-cookies, tiny-cookie, cookie_js, and more). All of them have a set function with the same 3-parameter signature. The benefit of this approach is that expires is optional, and other attributes can be set without having to pass a value for it. I think it would be strange and unexpected for PHP to require an expires value to be passed **even if I only want to set one of the other options.** Andrey, I understand your argument about expires being treated differently from the other options, but in my opinion this isn't sufficient reason to require a separate parameter before other attributes can be set, or to break from the convention of existing cookie-handling libraries that developers are familiar with. Kind regards, Theodore Brown