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
>
>

Reply via email to