Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96465
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZbHSuOBM58GxCLeT9VHGkDAZa5M7f-aLBXR7=pNg1JrA@mail.gmail.com>
References: <CAGa2bXb0CKP6=eZZk2atR5XGtR8JmQ3FG756wn0J7kkPGYFyZg@mail.gmail.com>
 <CAGa2bXYShMMU964gtq4VZfkBssJftJX-k2j+hRh6_YAyxm9mUw@mail.gmail.com>
 <1E4CA882-D433-413A-A369-E6340DD0078A@koalephant.com> <CAGa2bXZbHSuOBM58GxCLeT9VHGkDAZa5M7f-aLBXR7=pNg1JrA@mail.gmail.com>
Date: Wed, 19 Oct 2016 15:03:01 +0900
Message-ID: <CAGa2bXb1MvAQts6kDbRsOAVexfXPcAaLPQrFeruss6S=1JaDMg@mail.gmail.com>
To: Stephen Reay <php-lists@koalephant.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>, Davey Shafik <davey@php.net>, 
	Xinchen Hui <laruence@php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: header() removes all header of the same name.
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi all,

On Wed, Oct 19, 2016 at 1:34 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
> On Wed, Oct 19, 2016 at 12:18 PM, Stephen Reay <php-lists@koalephant.com>=
 wrote:
>> I still have an issue with that. I believe the correct behaviour here is=
 (assuming the `replace` argument to header() is honoured) what you=E2=80=
=99re seeing. Yes, it might be *unexpected* for new users, but its also *ex=
pected* by millions of current users/projects.
>>
>> I would suggest perhaps a warning on the header() docs page, and perhaps=
 an example to avoid the issue on the Session handling page.
>>
>> Leaving it as-is, with improved docs means all functionality is *possibl=
e* with the right arguments.
>>
>> Changing to your proposal means advanced use-cases are *impossible* with=
 any arguments.
>>
>>
>> I realise you=E2=80=99re trying to remove WTF cases, but I don=E2=80=99t=
 think removing advanced capabilities is the way to do that.
>
> Yes. Even framework developer(?) seems to have current behavior.
>
> In general, users shouldn't touch session ID. In case of user really
> want to modify session ID cookie, following could be done.
>
> <?php
> ob_start();
> session_start();
> header_remove('Set-Cookie');
> header('Set-Cookie: PHPSESSID=3Dxxxx something');
> ?>
>
> Make header_remove() able to delete 'Set-Cookie' header. (Current behavio=
r)
> Make header() able to send 'Set-Cookie' header. (Current behavior, but
> not remove session ID cookie)
>
> This allows users to send arbitrary session ID cookie when it is
> needed really needed, while avoiding accidental session ID cookie
> removal.
>
> What do you think?

Another idea for session ID cookie and Set-Cookie header protection.

Since we have setcookie() function, how about to have cookie
dedicated functions for cookie header manipulation.

I'm about to create new feature request as follows:
---------------------
Protect session ID and other cookies from header(), header_remove()
---------------------
header() removes any previously defined headers.
header('Set-Cookie: something') / header_remove() deletes session ID
and other Set-Cookie headers. Cookies should be protected from
header()/header_remove().

Instead, create new cookie functions

cookie_set() - Set cookie header (setcookie() alias)
cookie_set_raw() - Set cookie header (setrawcookie alias)
cookie_custom() - Set cookie with custom style.
                           (The same as header(sprintf('Set-Cookie:
%s', something));
cookie_remove() - Remove all cookie header. $name parameter is cookie
name to be deleted.

Protect Set-Cookie headers from header() and header_remove()
----------------------

This implementation is cleaner because core to session
dependency is not required. It is also good to have naming standard
confirming cookie function names. i.e. Cookie functions should be
named cookie_*() according to CODING_STANDARDS.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net