Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:96506 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 33803 invoked from network); 20 Oct 2016 08:23:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Oct 2016 08:23:58 -0000 Authentication-Results: pb1.pair.com smtp.mail=php-lists@koalephant.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=php-lists@koalephant.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain koalephant.com designates 206.123.115.54 as permitted sender) X-PHP-List-Original-Sender: php-lists@koalephant.com X-Host-Fingerprint: 206.123.115.54 mail1.25mail.st Received: from [206.123.115.54] ([206.123.115.54:47918] helo=mail1.25mail.st) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id BE/A1-24564-C1F78085 for ; Thu, 20 Oct 2016 04:23:58 -0400 Received: from [10.0.1.23] (unknown [183.89.46.225]) by mail1.25mail.st (Postfix) with ESMTPSA id 6EAF960847; Thu, 20 Oct 2016 08:23:36 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) In-Reply-To: Date: Thu, 20 Oct 2016 15:23:30 +0700 Cc: Stanislav Malyshev , "internals@lists.php.net" , Davey Shafik , Xinchen Hui Content-Transfer-Encoding: quoted-printable Message-ID: <59D6B40B-DC64-43A3-AED4-CD5C9C15B6BA@koalephant.com> References: <1eab7492-596c-ffd2-81ed-0eb9256a033e@gmail.com> <0B722A15-A29F-498B-987F-F6BA5AA49EEF@bobs-bits.com> To: Yasuo Ohgaki X-Mailer: Apple Mail (2.3124) Subject: Re: [PHP-DEV] header() removes all header of the same name. From: php-lists@koalephant.com (Stephen Reay) Hi Yasuo, > On 20 Oct 2016, at 15:10, Yasuo Ohgaki wrote: >=20 > Hi Stephen, >=20 > On Thu, Oct 20, 2016 at 4:48 PM, Stephen Reay = wrote: >>=20 >> Just to make my earlier point of view crystal clear: As a purely = userland party and someone maintaining a PHP framework, I don=E2=80=99t = think it=E2=80=99s acceptable to limit which headers = header()/header_remove() can operate on, particularly when the problem = you=E2=80=99re trying to =E2=80=98solve=E2=80=99 is simply incorrect use = of the functions available. It *is* possible to achieve any outcome = desired with *correct* use of the header, session and cookie functions = (and assuming the $replace argument to header() works correctly). >>=20 >> I still believe the way to solve this issue is with better = information about usage, not by removing existing functionality. >>=20 >> So, please do *not* consider this to be an acceptable solution. >=20 > The idea is to separate HTTP header handling functions. >=20 > - header*() for any HTTP headers except 'Set-Cookie' > - cookie*() for only 'Set-Cookie' header >=20 > Developer does not lose anything. The Developer *loses* what s/he has *now* - a fully functional header() = function. >=20 > As you mention, custom 'Set-Cookie' header is for advanced users. > Those people wouldn't have problems with new API. Those people shouldn=E2=80=99t have problems using header() properly. >=20 > With this new API, we'll have standard confirming function names for > cookie functions as a bonus, too. (I'm enthusiastic to clean up and > have consistent function names as you might know.) >=20 I don=E2=80=99t have a problem with improved function names. I have a = problem with removing functionality that is basically only ever going to = be used by advanced developers, because it has *slightly* non obvious = behaviour that could be fixed by a simple documentation note. Please understand: *no* =E2=80=9Csolution" where header() loses the = ability to write any arbitrary header will be acceptable in my opinion. > Regards, >=20 > -- > Yasuo Ohgaki > yohgaki@ohgaki.net >=20 Cheers Stephen