On 03 Nov 2014, at 02:21, Dan Ackroyd dan...@basereality.com wrote:
On 2 November 2014 15:10, Rowan Collins rowan.coll...@gmail.com wrote:
Wait, what does session handling have to do with any of this?
Sorry, I completely failed to write what I was trying to say there.
I meant that like
On 02 11 2014, at 01:33, Rowan Collins rowan.coll...@gmail.com wrote:
On 01/11/2014 22:24, Andrea Faulds wrote:
Perhaps it would be worth ditching any attempts to change setcookie() (just
keep it around for backwards-compatibility), and to instead add a new
function, function family, or
Florian wrote:
On the PR https://github.com/php/php-src/pull/795/ of the setcookie patch
to become compliant with the HTTP RFC,
There are some facts:
- the current way does not follow the HTTP RFC.
Please stop saying this, it isn't true.
From rfc6265:
Servers SHOULD NOT include more than one
Andrea wrote:
Perhaps it would be worth ditching any attempts to change setcookie() (just
keep it around for backwards-compatibility), and to instead add a new
function, function family, or indeed class for cookie handling.
Thoughts? Any idea what such an API might look like?
I think this API
On 2 November 2014 13:49:15 GMT, Dan Ackroyd dan...@basereality.com wrote:
Andrea wrote:
Perhaps it would be worth ditching any attempts to change setcookie()
(just keep it around for backwards-compatibility), and to instead add a
new function, function family, or indeed class for cookie handling.
Hi!
The behaviour of PHP is ABSOLUTELY in compliance with the RFC 6265.
Setting two headers may not follow best practice but it is conformant,
and it is only doing what the users PHP script told it to do.
I think I agree here - we're providing a low level API, and if somebody
uses this API in
On 2 November 2014 15:10, Rowan Collins rowan.coll...@gmail.com wrote:
Wait, what does session handling have to do with any of this?
Sorry, I completely failed to write what I was trying to say there.
I meant that like the session handling functions and setcookie are
similar in that:
* They
Hi list,
On the PR https://github.com/php/php-src/pull/795/ of the setcookie patch
to become compliant with the HTTP RFC, a valid use case for not throwing a
warning when running setcookie() twice with the same name: deleting cookies
(setcookie('name', '', ...);). It's thus been proposed to add
On 01/11/14 13:09, Florian Margaine wrote:
Hi list,
On the PR https://github.com/php/php-src/pull/795/ of the setcookie patch
to become compliant with the HTTP RFC, a valid use case for not throwing a
warning when running setcookie() twice with the same name: deleting cookies
(setcookie('name',
On 01/11/2014 21:10, Alexander Kurilo wrote:
What should be done? Trying to keep BC at a minimum by adding an
unsetcookie() method and add warnings? Try to detect the deletion of
cookies (empty value) and add warnings to keep even more BC?
Just in case: I believe cookies are removed not by
On 1 Nov 2014, at 21:47, Rowan Collins rowan.coll...@gmail.com wrote:
On 01/11/2014 21:10, Alexander Kurilo wrote:
What should be done? Trying to keep BC at a minimum by adding an
unsetcookie() method and add warnings? Try to detect the deletion of
cookies (empty value) and add warnings to
On 01/11/2014 22:24, Andrea Faulds wrote:
Perhaps it would be worth ditching any attempts to change setcookie() (just
keep it around for backwards-compatibility), and to instead add a new function,
function family, or indeed class for cookie handling. Some sort of sane API
which would allow
How about delaying that warning until the headers are sent?
I don't think there would be any benefit to that. The only possible
scenarios are:
i) People sending duplicate headers by accident. When they see the
error, they should fix their code, so the error goes away.
ii) People who are
On 8 September 2014 09:09, Ferenc Kovacs tyr...@gmail.com wrote:
On Mon, Sep 8, 2014 at 9:15 AM, Sherif Ramadan theanomaly...@gmail.com
wrote:
Actually, we shouldn't be doing that all. We should simply just overwrite
the header. It wouldn't make much sense to set two headers with the same
Hi!
On Sat, Sep 6, 2014 at 5:38 AM, Florian Margaine flor...@margaine.com
wrote:
Hi,
This is a minor BC break, but still a BC break, so worth discussing on this
ML.
When a second setcookie() is done with the same name, a warning is emitted,
because the ietf rfc 6265 says it *should* only
Actually, we shouldn't be doing that all. We should simply just overwrite
the header. It wouldn't make much sense to set two headers with the same
cookie name when we can just overwrite it.
On Mon, Sep 8, 2014 at 2:50 AM, Tjerk Meesters tjerk.meest...@gmail.com
wrote:
Hi!
On Sat, Sep 6,
On Mon, Sep 8, 2014 at 9:15 AM, Sherif Ramadan theanomaly...@gmail.com
wrote:
Actually, we shouldn't be doing that all. We should simply just overwrite
the header. It wouldn't make much sense to set two headers with the same
cookie name when we can just overwrite it.
that would be a bigger
Hi,
This is a minor BC break, but still a BC break, so worth discussing on this
ML.
When a second setcookie() is done with the same name, a warning is emitted,
because the ietf rfc 6265 says it *should* only send one Set-Cookie header
per name.
This is fine when display_errors is set to off.
18 matches
Mail list logo
