Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:96534 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 20185 invoked from network); 21 Oct 2016 04:38:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Oct 2016 04:38:32 -0000 Authentication-Results: pb1.pair.com header.from=php-lists@koalephant.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=php-lists@koalephant.com; spf=pass; 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:56236] helo=mail1.25mail.st) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A7/BE-24564-7CB99085 for ; Fri, 21 Oct 2016 00:38:31 -0400 Received: from [10.0.1.23] (unknown [183.89.46.225]) by mail1.25mail.st (Postfix) with ESMTPSA id D7D61604A2; Fri, 21 Oct 2016 04:38:09 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) In-Reply-To: Date: Fri, 21 Oct 2016 11:38:02 +0700 Cc: Niklas Keller , Stanislav Malyshev , "internals@lists.php.net" , Davey Shafik , Xinchen Hui Content-Transfer-Encoding: quoted-printable Message-ID: <86B1DB4D-DE72-4BF7-A407-B2C3A8538799@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) Is it normal to alter (or support multiple) function signatures like = this, 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_* functions, and then deprecate set cookie later? (ala mysql =3D> = mysqli) As for the specifics - I kind of like.. Niklas (I think?) suggestion = where 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 - = the 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 \DateTimeInterface 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 essential really. If the user can generate a UNIX = timestamp, they should be able to format it to RFC1123 themselves too, = no? While you=E2=80=99re looking at this. DateTime::COOKIE (and DATE_COOKIE) = seem to be using RFC850 format, but with a 4-digit year. Besides being a = bit of a mis-match of formats, RFC850 is considered =E2=80=9Cobsolete=E2=80= =9D now, and perhaps should be replaced by RFC1123 (basically, no = dashes, short day name). Cheers Stephen > On 21 Oct 2016, at 09:51, Yasuo Ohgaki wrote: >=20 > On Fri, Oct 21, 2016 at 9:35 AM, Yasuo Ohgaki = wrote: >> On Thu, Oct 20, 2016 at 9:21 PM, Niklas Keller = wrote: >>> Before we even discuss disallowing `header("set-cookie")`, we should = have a >>> sane cookie API, e.g. one that like `setcookie($name, $value, = $flags)`. >>>=20 >>> That's also the way we implemented it in Aerys >>> = (https://github.com/amphp/aerys/blob/9a7327f062aa678408dfe4f4c3c7f479db16f= 187/lib/Response.php#L49-L58). >>> It's a simple wrapper around `addHeader` to make life easier, but it = doesn't >>> restrict developers to call `setHeader` and replace all `set-cookie` >>> headers. >>=20 >> We choose current API for reason. It does not look pretty. >> This is patch allow array config for 3rd param for setcookie(). >>=20 >> https://gist.github.com/yohgaki/b86e07cd450777422c1a467166cd2fd3 >>=20 >> I suppose some of us will have opinions having this kind of code(s). >>=20 >> Any comments? >=20 > Execution example. >=20 > [yohgaki@dev github-php-src]$ cat t13.php > setcookie('A', 'B', ['httponly'=3D>1, 'path'=3D>'foo', > 'expires'=3D>time()+999, 'secure'=3D>1, 'domain'=3D>'example.com']); > setcookie('A', 'B', ['httponly'=3D>1] ); > setcookie('A', 'B', 999); > setcookie('A', 'B', time()+999); >=20 > echo 'OK'; > [yohgaki@dev github-php-src]$ ./php-cgi t13.php > X-Powered-By: PHP/7.2.0-dev > Set-Cookie: A=3DB; expires=3DFri, 21-Oct-2016 02:55:31 GMT; = Max-Age=3D999; > path=3Dfoo; domain=3Dexample.com; secure; HttpOnly > Set-Cookie: A=3DB; HttpOnly > Set-Cookie: A=3DB; expires=3DThu, 01-Jan-1970 00:16:39 GMT; = Max-Age=3D-1477016533 > Set-Cookie: A=3DB; expires=3DFri, 21-Oct-2016 02:55:31 GMT; = Max-Age=3D999 > Content-type: text/html; charset=3DUTF-8 >=20 > OK >=20 > If PHP has named parameter, we don't need this patch. > Dose anyone working on named parameter? >=20 > One issue of this patch is strict types. It ruins strictly typed > parameter because array option parameters won't be checked by PHP. >=20 > -- > Yasuo Ohgaki > yohgaki@ohgaki.net >=20