RE: [PHP-DEV] [Q] Session provider & returning FAILURE from PS_OPEN_FUNC?
| From: | Eric Stenson | Date: | Wed, 24 Jun 2015 17:58:04 +0000 |
| Subject: | RE: [PHP-DEV] [Q] Session provider & returning FAILURE from PS_OPEN_FUNC? | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-86851@lists.php.net to get a copy of this message | ||
From: Chris Wright
Sent: Wednesday, June 24, 2015 6:57 AM
> > On 23 June 2015 at 23:09, Eric Stenson <ericsten@microsoft.com> wrote:
> > Quick behavioral question:
> >
> > If an extension is implementing a Session handler, and returns FAILURE from its
> > PS_OPEN_FUNC(), will the extension receive subsequent PS_READ_FUNC()/PS_WRITE_FUNC()
> > calls?
> >
> > Also, if an extension returns FAILURE from its PS_OPEN_FUNC(), will the extension
> > receive a PS_CLOSE_FUNC()/PS_DESTROY_FUNC() call?
>
> No to all, if you return FAILURE then it results in an E_ERROR before the point where
> the session state is marked as active, i.e. it's fatal, so no further calls to anything
> will be made.
Hunh. That's weird, because in a repro case, I am seeing the WinCache session handler
getting called back for PS_READ_FUNC() after returning FAILURE from PS_OPEN_FUNC().
Looks like coming through the SessionHandler::read(string id) method is continuing to call
PS(default_mod)->s_read even though ->s_open failed. I believe this is because
the PS(mod_user_is_open) is being set to 1, despite the fact that the ->s_open failed.
http://lxr.php.net/xref/PHP_TRUNK/ext/session/mod_user_class.c#50
Do you want a bug opened on this?
>
> http://lxr.php.net/xref/PHP_TRUNK/ext/session/session.c#488
>
Thank you for the pointer! Now that I see that the session extension is tracing
the error, I won't bother adding even more tracing to WinCache. However, it does
seem that extra error checking is required.
Thx!
--E.