Hi all,
I didn't answer this question and would like to make my point of view clear.
On Thu, Oct 20, 2016 at 9:41 PM, Stephen Reay wrote:
> Why is your concern so focussed on solving problems for inexperienced
> developers, who are effectively using functions incorrectly, at the expense
> of e
Hi!
> 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]])
> (Ke
Hi Stephen,
On Fri, Oct 21, 2016 at 5:23 PM, Stephen Reay wrote:
>> On 21 Oct 2016, at 13:32, Yasuo Ohgaki wrote:
>>
>> Hi Stephen,
>>
>> On Fri, Oct 21, 2016 at 1:38 PM, Stephen Reay
>> wrote:
>>> Is it normal to alter (or support multiple) function signatures like this,
>>> when you want to
On 21/10/16 05:38, Stephen Reay 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
> On 21 Oct 2016, at 13:32, Yasuo Ohgaki wrote:
>
> Hi Stephen,
>
> On Fri, Oct 21, 2016 at 1:38 PM, Stephen Reay
> 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 lea
Hi Stephen,
On Fri, Oct 21, 2016 at 1:38 PM, Stephen Reay 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 t
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 specif
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)`.
>>
>> That's also the way we imple
Hi Niklas and all,
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)`.
>
> That's also the way we implemented it in Aerys
> (https://github.com
On 10/20/2016 4:58 PM, Guy Marriott wrote:
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 w
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, Oc
Hi Stats,
On Fri, Oct 21, 2016 at 5:54 AM, Stanislav Malyshev 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
Hi Stephen,
On Thu, Oct 20, 2016 at 9:41 PM, Stephen Reay wrote:
>> I don't want to get bug report that session lost or some important
>> cookie lost somehow.
>
> Why is your concern so focussed on solving problems for inexperienced
> developers, who are effectively using functions incorrectly,
Hi!
> 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
On 20.10.2016 at 14:15, Stephen Reay wrote:
> As with Niklas, I have no vote, so my *only* option to prevent what I
> consider to be a bad decision, is to post to this thread and hope that enough
> of those who *do* have voting rights, reject the proposal.
>
> I understand what you’re proposing
Hi Yasuo,
> On 20 Oct 2016, at 19:21, Yasuo Ohgaki wrote:
>
> Hi Ptephen,
>
> On Thu, Oct 20, 2016 at 9:15 PM, Stephen Reay
> wrote:
>> As with Niklas, I have no vote, so my *only* option to prevent what I
>> consider to be a bad decision, is to post to this thread and hope that
>> enough o
Hi Niklas,
On Thu, Oct 20, 2016 at 9:21 PM, Niklas Keller wrote:
> 2016-10-20 13:41 GMT+02:00 Yasuo Ohgaki :
>>
>> Hi Stephen,
>>
>> On Thu, Oct 20, 2016 at 8:24 PM, Stephen Reay
>> wrote:
>> > The *only* solution that retains full control for the developer, is no
>> > change. Any “magic” about
Hi Ptephen,
On Thu, Oct 20, 2016 at 9:15 PM, Stephen Reay wrote:
> As with Niklas, I have no vote, so my *only* option to prevent what I
> consider to be a bad decision, is to post to this thread and hope that enough
> of those who *do* have voting rights, reject the proposal.
It's okay, but a
2016-10-20 13:41 GMT+02:00 Yasuo Ohgaki :
> Hi Stephen,
>
> On Thu, Oct 20, 2016 at 8:24 PM, Stephen Reay
> wrote:
> > The *only* solution that retains full control for the developer, is no
> > change. Any “magic” about “untouchable” cookie headers (e.g. forcing the
> > session cookie header afte
Hi Yasuo,
As with Niklas, I have no vote, so my *only* option to prevent what I consider
to be a bad decision, is to post to this thread and hope that enough of those
who *do* have voting rights, reject the proposal.
I understand what you’re proposing. But honestly I don’t even agree with the
Hi Stephen,
On Thu, Oct 20, 2016 at 8:24 PM, Stephen Reay wrote:
> The *only* solution that retains full control for the developer, is no
> change. Any “magic” about “untouchable” cookie headers (e.g. forcing the
> session cookie header after userland cookie headers) takes away options for
> the
Hi Niklas,
On Thu, Oct 20, 2016 at 7:39 PM, Niklas Keller wrote:
> 016-10-20 11:57 GMT+02:00 Yasuo Ohgaki :
>>
>> Hi Niklas,
>>
>> On Thu, Oct 20, 2016 at 6:01 PM, Niklas Keller wrote:
>> >
>> > same here, it's not acceptable to limit header and restrict
>> > `set_cookie`.
>> > Just think about
Hi Niklas,
There is even a userland hook for the specific functionality you mention:
header_register_callback().
But I would argue that no fix is necessary. If you as a developer call
session_start(), and then later call header(‘Set-Cookie:…’) with replace left
as true, I think it’s safe to a
2016-10-20 11:57 GMT+02:00 Yasuo Ohgaki :
> Hi Niklas,
>
> On Thu, Oct 20, 2016 at 6:01 PM, Niklas Keller wrote:
> >
> > same here, it's not acceptable to limit header and restrict `set_cookie`.
> > Just think about all those frameworks that would have to specialcase
> setting
> > headers now and
Hi Niklas,
On Thu, Oct 20, 2016 at 6:01 PM, Niklas Keller wrote:
>
> same here, it's not acceptable to limit header and restrict `set_cookie`.
> Just think about all those frameworks that would have to specialcase setting
> headers now and have to use the cookie API then.
>
> If you want to prote
2016-10-20 10:28 GMT+02:00 Yasuo Ohgaki :
> Hi Stephen,
>
> On Thu, Oct 20, 2016 at 5:23 PM, Stephen Reay
> wrote:
> > Please understand: *no* “solution" where header() loses the ability to
> write any arbitrary header will be acceptable in my opinion.
>
> Thank you for feedback.
> I'll include v
Hi Stephen,
On Thu, Oct 20, 2016 at 5:23 PM, Stephen Reay wrote:
> Please understand: *no* “solution" where header() loses the ability to write
> any arbitrary header will be acceptable in my opinion.
Thank you for feedback.
I'll include vote option for prohibiting 'Set-Cookie' for header*()
R
Hi Yasuo,
> On 20 Oct 2016, at 15:10, Yasuo Ohgaki wrote:
>
> Hi Stephen,
>
> On Thu, Oct 20, 2016 at 4:48 PM, Stephen Reay wrote:
>>
>> Just to make my earlier point of view crystal clear: As a purely userland
>> party and someone maintaining a PHP framework, I don’t think it’s acceptable
Hi Stephen,
On Thu, Oct 20, 2016 at 4:48 PM, Stephen Reay wrote:
>
> Just to make my earlier point of view crystal clear: As a purely userland
> party and someone maintaining a PHP framework, I don’t think it’s acceptable
> to limit which headers header()/header_remove() can operate on, particu
Hi All,
Just to make my earlier point of view crystal clear: As a purely userland party
and someone maintaining a PHP framework, I don’t think it’s acceptable to limit
which headers header()/header_remove() can operate on, particularly when the
problem you’re trying to ‘solve’ is simply incorre
Hi Stas,
I posted an an idea for preventing accidental cookie deletion.
'Set-Cookie' is a HTTP header, but provide dedicated functions for it. I pasted
it with a little modification.
What do you think?
Bottom line is I would like to prevent lost session ID by header()
in the future.
Implement c
Hi!
> There is 2 issues.
> - header() removes all headers of the same name including 'Set-Cookie'
> - header() ignores replace flag. (This one is easy to fix)
We have the flag, so if it doesn't work it should be fixed. Also, one
should use setcookie() for cookies, usually.
> Possible resolut
Hi Yasuo,
I agree there are probably a lot using the default, but I think it’s reasonable
to expect anyone using a header(‘Set-Cookie:..’); call rather than setcookie()
to be aware of the 2nd argument for header(), so this solution sounds good to
me.
Cheers
Stephen
> On 18 Oct 2016, at 18:0
Hi Stephen,
On Tue, Oct 18, 2016 at 5:54 PM, Stephen Reay wrote:
> If the replace flag was fixed, isn’t this then just a case of making sure
> userland sets replace to false if they want existing set-cookie headers
> retained?
Yes and no.
If users use the replace flag correctly, then it will
(Apologies for the dupe, re-sending for the list.)
If the replace flag was fixed, isn’t this then just a case of making sure
userland sets replace to false if they want existing set-cookie headers
retained?
Removing the ability to write a custom Set-Cookie header introduces a bigger
problem th
Hi all,
I understand why header() is made to remove all headers of the same
name. This is needed in some cases, but it does not work well for some
cases.
We need to decide what to do with
https://bugs.php.net/bug.php?id=72997
There is 2 issues.
- header() removes all headers of the same name i
36 matches
Mail list logo
