From: Chris Wright Sent: Wednesday, June 24, 2015 6:57 AM > > On 23 June 2015 at 23:09, Eric Stenson <erics...@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.
