Hey all,
Just a quick note (a couple of days late, sorry) that the vote for the RFC
" Add PHP Engine Identifier Constant" failed, 8 to 9.
I'll consider this RFC closed at this point.
Thanks all!
- Davey
Hi Rowan,
On Tue, Sep 27, 2016 at 3:02 AM, Rowan Collins wrote:
> On 26/09/2016 07:02, Stanislav Malyshev wrote:
>>>
>>> http://php.net/manual/en/session.security.php
>>> >http://php.net/manual/en/function.session-regenerate-id.php
>>
>> It looks like those need some polishing. If somebody with n
On Tue, Sep 27, 2016 at 7:52 AM, Yasuo Ohgaki wrote:
> So you do not think timestamp based session management is not
> mandatory. Then how do you accomplish securing session data?
Sorry, above sentence should be
So you think timestamp based session management is not
mandatory. Then how do you ac
On 09/26/2016 10:52 PM, Davey Shafik wrote:
On Mon, Sep 26, 2016 at 2:32 PM, Rowan Collins
wrote:
On 26/09/2016 20:37, Paul Jones wrote:
tl;dr: Gauging interest in an extension for server-side PHP request and
response objects (*not* HTTP messages per se; see below) prior to writing
an RFC f
Hi Stas,
On Mon, Sep 26, 2016 at 3:02 PM, Stanislav Malyshev wrote:
>> Timestamp based session management is required to manage session as it
>> should. I've updated the session manual pages a while a ago to explain
>> why.
>
> Could you explain what you mean here? "As it should" is kind of broad
Hi!
> Because current session module cannot distinguish if session ID come
> from outside, i.e. session cookie/trans sid, or script. This could be
> improved, but user should control session.use_strice_mode currently.
I think quite the opposite - user's shouldn't change stict_mode settings
in run
Hi Stas,
On Mon, Sep 26, 2016 at 3:18 PM, Stanislav Malyshev wrote:
>> Please read session_regenerate_id() example #2.
>>
>> Example #2 Avoiding lost session by session_regenerate_id()
>
> In this example, why you do session_commit() in my_session_start()?
> There's no point in writing stale sess
On Mon, Sep 26, 2016 at 2:32 PM, Rowan Collins
wrote:
> On 26/09/2016 20:37, Paul Jones wrote:
>
>> tl;dr: Gauging interest in an extension for server-side PHP request and
>> response objects (*not* HTTP messages per se; see below) prior to writing
>> an RFC for them on the wiki.
>>
>
> This sou
On 26 09 2016, at 21:37, Paul Jones wrote:
>
> Hi all,
>
> tl;dr: Gauging interest in an extension for server-side PHP request and
> response objects (*not* HTTP messages per se; see below) prior to writing an
> RFC for them on the wiki.
>
Did you include pecl/http in your research?
It looks
On 26/09/2016 20:37, Paul Jones wrote:
tl;dr: Gauging interest in an extension for server-side PHP request and
response objects (*not* HTTP messages per se; see below) prior to writing an
RFC for them on the wiki.
This sounds like an interesting project, but I have a few questions.
First, t
Hey Paul,
On 26 Sep 2016 21:38, "Paul Jones" wrote:
>
> Hi all,
>
> tl;dr: Gauging interest in an extension for server-side PHP request and
response objects (*not* HTTP messages per se; see below) prior to writing
an RFC for them on the wiki.
>
> * * *
>
> From time to time we've all heard the co
Hi Paul,
Thank you for spending the time to actually put this together!
I've been dipping my toes in the water asking around about this (sort of)
as well and feedback so far has been "That sounds great but I don't think
there is enough interest." So I'm very interested to see what kind of
response
Hi all,
tl;dr: Gauging interest in an extension for server-side PHP request and
response objects (*not* HTTP messages per se; see below) prior to writing an
RFC for them on the wiki.
* * *
From time to time we've all heard the complaint that PHP has no built-in
request object to represent the
Hi everyone,
A longstanding, documented issue in PHP is that casts between objects
and arrays leave numeric keys inaccessible. Specifically, numeric string
properties on objects become inaccessible string keys in arrays, and
integer keys in arrays become inacessible integer properties on objec
On 26/09/2016 07:02, Stanislav Malyshev wrote:
http://php.net/manual/en/session.security.php
>http://php.net/manual/en/function.session-regenerate-id.php
It looks like those need some polishing. If somebody with native English
volunteers it'd be great, otherwise I'll do it a bit later.
I was a
On Tue, Sep 13, 2016 at 10:54 AM, Adam Baratz wrote:
> > I noticed that there's a stale version of a supported package on pecl:
>> > https://pecl.php.net/package/pdo_dblib
>> >
>> > Should this be removed to avoid confusion?
>>
>> Alternatively a note might be added, as it has been done for
>> PE
Results for project PHP master, build date 2016-09-26 06:24:45+03:00
commit: 56ff613
previous commit:a137a1e
revision date: 2016-09-25 20:58:09+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On 25.09.2016 at 14:20, Dan Ackroyd wrote:
> On 25 September 2016 at 06:29, Pierre Joye wrote:
>
>> I am pretty sure it is by design (for what I can remember)
>
> I do not believe that is correct.
>
> The commit message* says: "Restore PHP-5.2 behaviour when passing null
> inside object scope
> On 26 Sep 2016, at 10:20, Pierre Joye wrote:
> I think it is
> clear now that this behavior is by design
No it is not.
You ignored my previous email which showed the commit message doesn't do what
it says. The code doesn't do what it says in the manual either.
If you're not going to read f
On Mon, Sep 26, 2016 at 4:06 AM, Niklas Keller wrote:
> 2016-09-25 20:58 GMT+02:00 Pierre Joye :
>> All I am saying is this is a BC break with little to no value because what
>> willing to support 7.1+ only can simply use the alternatives.
>
> Which alternatives?
Wrong wording. In any case this
20 matches
Mail list logo
