Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78563 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 76682 invoked from network); 2 Nov 2014 21:38:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Nov 2014 21:38:24 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.67 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.67 smtp67.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.67] ([108.166.43.67:57411] helo=smtp67.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DD/71-62688-E44A6545 for ; Sun, 02 Nov 2014 16:38:23 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp25.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id D74E9180126; Sun, 2 Nov 2014 16:38:19 -0500 (EST) X-Virus-Scanned: OK Received: by smtp25.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id D4EF718014B; Sun, 2 Nov 2014 16:38:18 -0500 (EST) X-Sender-Id: smalyshev@sugarcrm.com Received: from Stass-MacBook-Pro.local (108-66-6-48.lightspeed.sntcca.sbcglobal.net [108.66.6.48]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:465 (trex/5.3.2); Sun, 02 Nov 2014 21:38:19 GMT Message-ID: <5456A44A.7090700@sugarcrm.com> Date: Sun, 02 Nov 2014 13:38:18 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Dan Ackroyd , Florian Margaine CC: Chris Wright , Ferenc Kovacs , Sherif Ramadan , Tjerk Meesters , PHP Internals References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] setcookie() minor BC break - fixes issue #67736 From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > The behaviour of PHP is ABSOLUTELY in compliance with the RFC 6265. > Setting two headers may not follow best practice but it is conformant, > and it is only doing what the users PHP script told it to do. I think I agree here - we're providing a low level API, and if somebody uses this API in a manner contrary to best practices, it's on them, but as long as it is not prohibited by the RFC, we should support this behavior in case the users have good reasons to do this. Yes, in 99% of cases it would not be a good reason - that's why it is not the best practice - but as it is not prohibited, there would be valid 1% of cases where it is required by the user. As I see now, the behavior of following user instructions does not break anything, right? It just allows the user to do something that the RFC says he SHOULD NOT do. But I don't think this is a priority to enforce best practices in a low level API, risking breaking BC and causing trouble. If there's a case for higher level API enforcing the best practices, fine, HTTP classes (like pecl/http ones) or frameworks can always handle this. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/