On 8 September 2014 09:09, Ferenc Kovacs <tyr...@gmail.com> wrote:
> On Mon, Sep 8, 2014 at 9:15 AM, Sherif Ramadan <theanomaly...@gmail.com>
> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
