Re: [PHP-DEV] setcookie() minor BC break - fixes issue #67736

[email protected] (Chris Wright)
Newsgroups php.internals
Message-ID <CAGAGxbYuimpj+phbNXn_3e_17vpGEkes7Pn5jCh9j27uZoOT8Q@mail.gmail.com>
On 8 September 2014 09:09, Ferenc Kovacs <[email protected]> wrote:
> On Mon, Sep 8, 2014 at 9:15 AM, Sherif Ramadan <[email protected]>
> wrote:
>
>> Actually, we shouldn't be doing that all. We should simply just overwrite
>> the header. It wouldn't make much sense to set two headers with the same
>> cookie name when we can just overwrite it.
>>
>>
>>
> that would be a bigger BC break, and without a warning, those people
> affected by the change will have a harder time figuring out what went wrong.
> and as was discussed both in the PR and the bugreport the rfc discourages
> but doesn't prohibit this behavior, so making it impossible for the
> userland to do it would be a bit of an arbitrary restriction.
> maybe we could do something like introducing a new $overwrite = true option
> to the function signature, but setcookie already has 7 arguments, so
> probably isn't a great idea.

How about changing the signature of setcookie() to:

bool setcookie (
    string $name
    [, string $value
    [, int $expire = 0
    [, string $path
    [, string $domain
    [, int $flags = 0
    [, bool $httponly = false
]]]]]])

And creating the following constants for use as flags:

const COOKIE_SECURE = 1;
const COOKIE_HTTPONLY = 2;
const COOKIE_OVERWRITE = 4;

This will also be a small BC break, but would potentially be a
graceful way to trim an argument off setcookie() with minimal impact
to users, making the signature more user-friendly (IMO) and allowing
additional functionality to be added in the future by means of more
flags.

Setting the value of COOKIE_SECURE to 1 covers what I suspect will be
the most common case where the value of this argument is not a bool or
NULL, i.e. specifying 1/0 to reduce line length. If the $httponly arg
is specified and not NULL it can override the value for that element
of $flags. Passing this last argument could emit an E_DEPRECATED,
either immediately or in the future.

This is also not an ideal solution and everyone may hate it, just
throwing it out there.

Thanks, Chris

> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.