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

Hi Stephen, On Fri, Oct 21, 2016 at 1:38 PM, Stephen Reay <php-lists@koalephant.com> wrote: > 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) 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. > > 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? 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 => value pairs in case we change the default. I cannot think of date generation use case. Is there good use case? > > 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). Good idea. It's not updated since 90's, I guess. The same topic pops up on occasion. https://tools.ietf.org/html/rfc6265#section-5.1.1 Do we have this algorithm somewhere already? Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net