Re: header() removes all header of the same name.

Is it normal to alter (or support multiple) function signatures like this, when you want to improve the name *and* improve the signature? Wouldn’t you just leave setcookie() as-is, introduce the new cookie_* functions, and then deprecate set cookie later? (ala mysql => mysqli) As for the specifics - I kind of like.. Niklas (I think?) suggestion where the flags array accepts either key => value pairs, or non-keyed flag values. Any non-string key is ignored and the value used as a ‘flag’ (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’t think I’d 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’re 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 “obsolete” 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 <yohgaki@ohgaki.net> wrote: > > On Fri, Oct 21, 2016 at 9:35 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: >> On Thu, Oct 20, 2016 at 9:21 PM, Niklas Keller <me@kelunik.com> wrote: >>> Before we even discuss disallowing �� \ 9��h���� >>> �header("set-cookie"), we should have a >>> sane cookie API, e.g. one that like setcookie($name, $value, >>> $flags). >>> >>> That's also the way we implemented it in Aerys >>> >>> (https://github.com/amphp/aerys/blob/9a7327f062aa678408dfe4f4c3c7f479db16f187/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. >> >> We choose current API for reason. It does not look pretty. >> This is patch allow array config for 3rd param for setcookie(). >> >> >> https://gist.github.com/yohgaki/b86e07cd450777422c1a467166cd2fd3 >> >> I suppose some of us will have opinions having this kind of code(s). >> >> Any comments? > > Execution example. > > [yohgaki@dev github-php-src]$ cat t13.php > <?php > setcookie('A', 'B', ['httponly'=>1, > 'path'=>'foo', > 'expires'=>time()+999, 'secure'=>1, > 'domain'=>'example.com']); > setcookie('A', 'B', ['httponly'=>1] ); > setcookie('A', 'B', 999); > setcookie('A', 'B', time()+999); > > echo 'OK'; > [yohgaki@dev github-php-src]$ ./php-cgi t13.php > X-Powered-By: PHP/7.2.0-dev > Set-Cookie: A=B; expires=Fri, 21-Oct-2016 02:55:31 GMT; Max-Age=999; > path=foo; domain=example.com; secure; HttpOnly > Set-Cookie: A=B; HttpOnly > Set-Cookie: A=B; expires=Thu, 01-Jan-1970 00:16:39 GMT; Max-Age=-1477016533 > Set-Cookie: A=B; expires=Fri, 21-Oct-2016 02:55:31 GMT; Max-Age=999 > Content-type: text/html; charset=UTF-8 > > OK > > If PHP has named parameter, we don't need this patch. > Dose anyone working on named parameter? > > One issue of this patch is strict types. It ruins strictly typed > parameter because array option parameters won't be checked by PHP. > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net >