FWIW Yasuo, I also think this is a bad idea. If you remove the ability to set cookie _headers_ with the header function then the function needs a more appropriate name - perhaps headerExceptCookie.
That makes 5 people opposed - 100% of the individuals who have responded in this thread. On Fri, Oct 21, 2016 at 10:41 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > Hi Stats, > > On Fri, Oct 21, 2016 at 5:54 AM, Stanislav Malyshev <smalys...@gmail.com> > wrote: > > > >> The idea is to separate HTTP header handling functions. > >> > >> - header*() for any HTTP headers except 'Set-Cookie' > >> - cookie*() for only 'Set-Cookie' header > > > > This does not look like a good design. First of all, HTTP spec allows > > multiple instances of any header. Second, making function with unobvious > > gotcha branch is usually bad design. Third, we are solving non-existing > > problem here - people should just use existing functions correctly and > > everything would be fine. > > Let's not spend any more time on this. > > OK. 4 people not in favor of Set-Cookie restriction for header*(). > > What about API clean up? > Since we have setcookie()/setrawcookie() already, we may clean up > current cookie API > > e.g. > - cookie_set/setcookie($name, [$value, [array $options]]) > (Keep current signature also) > - cookie_set_raw/setrawcookie($name, [$value, [array $options]]) > (Keep current signature also) > - cookie_remove($name), cookie_list() > (These may be optional to you) > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
