Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:96519 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 62228 invoked from network); 20 Oct 2016 12:15:41 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Oct 2016 12:15:41 -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:54023] helo=mail1.25mail.st) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 31/07-24564-D65B8085 for ; Thu, 20 Oct 2016 08:15:41 -0400 Received: from [10.0.1.23] (unknown [183.89.46.225]) by mail1.25mail.st (Postfix) with ESMTPSA id D30A9609FA; Thu, 20 Oct 2016 12:15:20 +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 19:15:14 +0700 Cc: Niklas Keller , Stanislav Malyshev , "internals@lists.php.net" , Davey Shafik , Xinchen Hui Content-Transfer-Encoding: quoted-printable Message-ID: <72B2986D-3C05-4929-9BDD-1A911FC9E793@koalephant.com> References: <1eab7492-596c-ffd2-81ed-0eb9256a033e@gmail.com> <0B722A15-A29F-498B-987F-F6BA5AA49EEF@bobs-bits.com> <59D6B40B-DC64-43A3-AED4-CD5C9C15B6BA@koalephant.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, As with Niklas, I have no vote, so my *only* option to prevent what I = consider to be a bad decision, is to post to this thread and hope that = enough of those who *do* have voting rights, reject the proposal. I understand what you=E2=80=99re proposing. But honestly I don=E2=80=99t = even agree with the premise that there is a *problem* that needs to be = fixed. Did you know that if you manually set the Content-Length header to less = than the actual body length, many browsers (Safari, Chrome, and FF = definitely) will stop reading/processing the response at the length you = specify? So should we also prevent setting Content-Length via header() ? Honestly I don=E2=80=99t understand how this is still a discussion. The = developer failed to set the $replace argument to false. At most I would = expect this to result in a documentation note warning about the use of = header(=E2=80=98Set-Cookie=E2=80=A6=E2=80=99). I appreciate you trying to make improvements, and I=E2=80=99d = *definitely* be in favour of the function naming cleanup you mentioned = earlier, but all of this =E2=80=9Cprotected=E2=80=9D headers and extra = function calls, because someone forgot to type =E2=80=9C, false=E2=80=9D = seems ridiculous to me honestly. Cheers Stephen > On 20 Oct 2016, at 18:41, Yasuo Ohgaki wrote: >=20 > Hi Stephen, >=20 > On Thu, Oct 20, 2016 at 8:24 PM, Stephen Reay = wrote: >> The *only* solution that retains full control for the developer, is = no >> change. Any =E2=80=9Cmagic=E2=80=9D about =E2=80=9Cuntouchable=E2=80=9D= cookie headers (e.g. forcing the >> session cookie header after userland cookie headers) takes away = options for >> the developer. >=20 > My cookie*() functions proposal allows developers to remove header by > cookie_remove() and can send any cookie header by cookie_custom(). > Therefore, developers have full control if they have to. >=20 > The only pain is that users may have to use cookie*() functions if we > disallow header('Set-Cookie') which will be a vote option. If there is > fully functional cookie*() functions, it will mitigate wrong > header('Set-Cookie') usage regardless of the vote result, hopefully. >=20 > Regards, >=20 > -- > Yasuo Ohgaki > yohgaki@ohgaki.net >=20