Many of you will just switch off because it's me spouting off again, but
hopefully some of you will listen ...
The current discussion on http response objects and other aspects of the
transmission process has brought out a few more 'what the ...' from some
of you and as with a lot of the 'modern'
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.
On 02/11/2014 09:46, Lester Caine wrote:
The current discussion on http response objects and other aspects of the
transmission process has brought out a few more 'what the ...' from some
of you and as with a lot of the 'modern' discussions, the reasons for
wanting something tend to be wrapped in
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
Hi!
Slightly off-topic, but how about the same thing for bugs.php.net and
patches?
I'd say this would be excellent - somebody contributing time to triage
the bugs on bugs.php.net and separating I made a typo but I'm sure it's
PHP's fault from I discovered a major case of broken but nobody
Hi!
I would like to propose the creation of a team to triage the pull requests
on GitHub, to help ensure that the pull requests are handled in a timely
manner. I am also volunteering to lead such a team, should the RFC be
approved.
I've read the proposal, and the idea of labeling the PRs and
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!
Also, removing $_GET and $_POST is a *massive*
backwards-compatibility break. I would vote against this proposal and
I hope everyone else will join me in doing so, for that reason
alone.
I think removing $_* is a no go and even discussing it is kind of
pointless unless somebody wants to
On Oct 31, 2014 11:48 PM, Miloslav Hůla miloslav.h...@gmail.com wrote:
I agree with Levi, that using FQN in annotations works. And I wrote
reasons why it is wrong. Moreover, IDEs works with aliases in annotations
well. The only missing fragment is, that you cannot access aliases
definitions in
12 matches
Mail list logo
