Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78548 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 98137 invoked from network); 1 Nov 2014 17:10:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Nov 2014 17:10:13 -0000 Authentication-Results: pb1.pair.com smtp.mail=florian@margaine.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=florian@margaine.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain margaine.com from 209.85.223.172 cause and error) X-PHP-List-Original-Sender: florian@margaine.com X-Host-Fingerprint: 209.85.223.172 mail-ie0-f172.google.com Received: from [209.85.223.172] ([209.85.223.172:58795] helo=mail-ie0-f172.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 0B/63-63593-2F315545 for ; Sat, 01 Nov 2014 12:10:11 -0500 Received: by mail-ie0-f172.google.com with SMTP id at20so3062677iec.31 for ; Sat, 01 Nov 2014 10:10:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=06lYw2qbLu0hk9OPZinNPGmUvoCUuhjFwqL0XlZSiRk=; b=J1qKXzcqMDYsOk+2tnzbziMkOQ+JGO5TiWipjUKqnxUfAydwTvbH9hRvtEQGc5UNNT 9f6I25/1v76MVI2oUP3yL9kzyHhK+TrtiuD4uvsCpNZSVn8BFc5Bguefmq61LeWIe7iv wiqoh0idWzpsC/ZB/mREFAayh6D7ROYXF48BmsNPslWETI4kOQuqgsH5mbZQC+tGjJwB pvMDfIdhLyDfgXZ8M9SfdZ1whPkYyeYfGi3LvQAcdQ9tlLyNhpTWs8ZfaY/cJWwb+79M thS6LjJAvZ+h9oyhLFaaqlB6e0ubbhInCDPmAgNqPEwEE/7laG/0+cah4fgqShbN2S8j 3T8A== X-Gm-Message-State: ALoCoQmgeDM/LfHy/oOdxVSJRyLhNQQNLcMguwA1KPtZlSrB7w6kIpQnvvty6UtEI3ZpJMRjpyVJ X-Received: by 10.50.3.97 with SMTP id b1mr5106040igb.12.1414861808415; Sat, 01 Nov 2014 10:10:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.149 with HTTP; Sat, 1 Nov 2014 10:09:48 -0700 (PDT) X-Originating-IP: [93.8.60.124] In-Reply-To: References: Date: Sat, 1 Nov 2014 18:09:48 +0100 Message-ID: To: Chris Wright Cc: Ferenc Kovacs , Sherif Ramadan , Tjerk Meesters , PHP Internals Content-Type: multipart/alternative; boundary=089e013cc32c7f84680506cf2f09 Subject: Re: [PHP-DEV] setcookie() minor BC break - fixes issue #67736 From: florian@margaine.com (Florian Margaine) --089e013cc32c7f84680506cf2f09 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi list, On the PR of the setcookie patch to become compliant with the HTTP RFC, a valid use case for not throwing a warning when running setcookie() twice with the same name: deleting cookies (setcookie('name', '', ...);). It's thus been proposed to add an unsetcookie() method. I'm not set on whether it's a good thing or not. I'm also not sure how to handle this. There are some facts: - the current way does not follow the HTTP RFC. - we cannot have the "last come last served" cookie because it's a BC break= . - the current functions cannot allow us to unset a cookie. What should be done? Trying to keep BC at a minimum by adding an unsetcookie() method and add warnings? Try to detect the deletion of cookies (empty value) and add warnings to keep even more BC? I'm unsure on what should be done and would like internals' opinion :-) On Tue, Sep 9, 2014 at 4:53 PM, Chris Wright wrote: > On 8 September 2014 09:09, Ferenc Kovacs wrote: > > On Mon, Sep 8, 2014 at 9:15 AM, Sherif Ramadan > > 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 sa= me > >> 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 discourag= es > > 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 =3D true > option > > to the function signature, but setcookie already has 7 arguments, so > > probably isn't a great idea. > > -- > > Ferenc Kov=C3=A1cs > > @Tyr43l - http://tyrael.hu > Regards, --=20 Florian Margaine --089e013cc32c7f84680506cf2f09--