Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:96539 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 36278 invoked from network); 21 Oct 2016 09:45:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Oct 2016 09:45:09 -0000 Authentication-Results: pb1.pair.com header.from=yohgaki@ohgaki.net; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=yohgaki@ohgaki.net; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender) X-PHP-List-Original-Sender: yohgaki@ohgaki.net X-Host-Fingerprint: 180.42.98.130 ns1.es-i.jp Received: from [180.42.98.130] ([180.42.98.130:48890] helo=es-i.jp) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EB/11-28528-3A3E9085 for ; Fri, 21 Oct 2016 05:45:09 -0400 Received: (qmail 97601 invoked by uid 89); 21 Oct 2016 09:45:04 -0000 Received: from unknown (HELO mail-qt0-f174.google.com) (yohgaki@ohgaki.net@209.85.216.174) by 0 with ESMTPA; 21 Oct 2016 09:45:04 -0000 Received: by mail-qt0-f174.google.com with SMTP id s49so79027437qta.0 for ; Fri, 21 Oct 2016 02:45:03 -0700 (PDT) X-Gm-Message-State: ABUngvfC9O7pqktj4opzRn0j2QdApSJ4ibWRIl5SrUXu9FPRQcDZogquJ8Z2su6gGJuo7PL3nnQefAAOSyvODA== X-Received: by 10.237.47.194 with SMTP id m60mr4938264qtd.55.1477043097497; Fri, 21 Oct 2016 02:44:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.38 with HTTP; Fri, 21 Oct 2016 02:44:16 -0700 (PDT) In-Reply-To: References: <1eab7492-596c-ffd2-81ed-0eb9256a033e@gmail.com> <0B722A15-A29F-498B-987F-F6BA5AA49EEF@bobs-bits.com> <59D6B40B-DC64-43A3-AED4-CD5C9C15B6BA@koalephant.com> Date: Fri, 21 Oct 2016 18:44:16 +0900 X-Gmail-Original-Message-ID: Message-ID: To: Stephen Reay Cc: Niklas Keller , Stanislav Malyshev , "internals@lists.php.net" , Davey Shafik , Xinchen Hui Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] header() removes all header of the same name. From: yohgaki@ohgaki.net (Yasuo Ohgaki) Hi Stephen, On Fri, Oct 21, 2016 at 5:23 PM, Stephen Reay wr= ote: >> On 21 Oct 2016, at 13:32, Yasuo Ohgaki wrote: >> >> Hi Stephen, >> >> On Fri, Oct 21, 2016 at 1:38 PM, Stephen Reay = wrote: >>> Is it normal to alter (or support multiple) function signatures like th= is, when you want to improve the name *and* improve the signature? Wouldn= =E2=80=99t you just leave setcookie() as-is, introduce the new cookie_* fun= ctions, and then deprecate set cookie later? (ala mysql =3D> mysqli) >> >> I'm lazy enough not to add new function entry point because the patch >> is to show how it will look like. >> >> Making aliases make life a little easier for both user and developer. >> I don't think we will deprecate (I mean deprecate and remove in the >> future) old functions. It will be there to avoid needless >> incompatibility. >> > > I=E2=80=99m not quite sure I understand. I thought the whole point of new= standardised function names is to allow eventual deprecation and removal o= f the inconsistent/confusing names? In PHP4, we might have removed some functions on occasion. I don't remember well. We have removed really unneeded functions in PHP5 like register_globals related functions. I renamed number of pgsql functions in PHP4, but I don't remove any aliases and I probably will not. Alias removal is very unlikely but possible. However, we have RFC for such changes. Chance for removing setcookie() is almost none. We cannot remove even problematic uniqid() probably. Regarding to have array parameters, session_start() is made to accept array parameter like this, but session_start() accepts void parameter before. Array is used because it's very annoying to have setcookie() like parameters. >>> >>> As for the specifics - I kind of like.. Niklas (I think?) suggestion wh= ere the flags array accepts either key =3D> value pairs, or non-keyed flag = values. Any non-string key is ignored and the value used as a =E2=80=98flag= =E2=80=99 (e.g. HttpOnly, Secure). Any non-string value would be casted to = string. >>> >>> This would obviously require slightly different usage by developers - t= he user would need to send a date/time (either a string or object that will= cast to a string in the right format) instead of a timestamp for expires. = If you want to special-case it, you could type-check for an instance of \Da= teTimeInterface and run ->format(\DateTime::COOKIE) instead of just casting= to string, but I don=E2=80=99t think I=E2=80=99d consider that to be essen= tial really. If the user can generate a UNIX timestamp, they should be able= to format it to RFC1123 themselves too, no? >> >> I have an idea to enable HttpOnly by default. Most applications will >> be safer by this change without any problems, but some applications >> may need to disable HttpOnly. So it's better to stick with key =3D> >> value pairs in case we change the default. >> > > That=E2=80=99s a good point. So perhaps anything with a boolean value bec= omes a keyword only? (i.e. keep it generic, with as little special-case han= dling of keywords/named values as possible) Oops, I mixed up session cookie and other cookie. I do have an idea to set HttpOnly by default for session ID cookie, but not for other cookies set by setcookie(). Rather than HttpOnly, we may have to consider enabling "Secure" for setcookie() by default in near future. Almost all web will enable TLS soon. https://github.com/amphp/aerys/blob/9a7327f062aa678408dfe4f4c3c7f479db16f18= 7/lib/Response.php#L49-L58 This is interface, so I cannot tell what it mean by "unkeyed values". ['HttpOnly'] means enable 'HttpOnly', probably. (I'm willing to add new function entry points for consistency, but I think API itself should be as simple as possible. It may sounds contradictory with my filter validation improvement RFC, but the proposal was made so that only implements mandatory API changes for the purpose) I would like to keep minimum feature, consistency and expandability. 'option_name' =3D> 'option_value' format should be kept access all functions. We do change some flags on occasion. Not only flipping true/false default, but also bool to integer. i.e. on/off flags to number of int constant options. > >> I cannot think of date generation use case. Is there good use case? > > What do you mean? You can=E2=80=99t think of a situation where the develo= per would be setting a cookie expiry date, or you can=E2=80=99t think of a = reason to cast a date time object to a string? OK. You would like to use DateTime object's string. Although we don't follow current RFC, but RFC has very specific rule for cookie's expiration time range and format. Allowing string expiration date is problematic and DateTime::timestamp() can be used to set proper UNIX timestamp. So current way is good. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net