php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #13300 Calling of session write handler after output buffer sent is stupid!
Submitted: 2001-09-14 07:55 UTC Modified: 2001-12-19 22:39 UTC
From: basil dot hussain at kodakweddings dot com Assigned:
Status: Closed Package: Session related
PHP Version: 4.0.5 OS: Linux
Private report: No CVE-ID: None
 [2001-09-14 07:55 UTC] basil dot hussain at kodakweddings dot com
I am experiencing the effects of bug #12968 too. However, it's not really a bug (as in there is something malfunctioning), but rather a BIG design flaw. The whole thing centres around the behaviour mentioned in the manual for the function session_set_save_handler():

"The 'write' handler is not executed until after the output stream is closed."

Because the output buffer is sent before the write handler is called, when the client browser is on a fast network connection (i.e. an internal LAN in my case too) it recieves the output and acts upon the 302 redirect HTTP header before the write handler has finished executing. However, in this case, because we are using MySQL, the session write handler function takes some time - especially so when your MySQL database is on a seperate host to the web server. This results in the page which is being re-directed to executing in it's entirity (including the session read/write handlers) before the original session write function finishes.

This is a MAJOR design flaw (nothing should ever rely upon the speed of a client connection), and I move that this behaviour be changed immediately. The session write handler should be called before the output buffer is sent, but still only after the script has finished executing.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-09-14 10:07 UTC] basil dot hussain at kodakweddings dot com
For now, I have found a workaround in the case of storing session data in MySQL.

All you simply need to do in your write handler function is to issue a WRITE locking query before the one that inserts/updates the session record and an unlocking query afterwards. This means that the SELECT query issued from the session read handler in the page that was re-directed to happens, it is queued until the session write from the previous page is finished.

So, instead of simply:

REPLACE INTO table_name (sess_id, mod_date, data) VALUES ('$sess_id', NOW(), '$value');

You will have:

LOCK TABLES table_name WRITE;
REPLACE INTO table_name (sess_id, mod_date, data) VALUES ('$sess_id', NOW(), '$value');
UNLOCK TABLES;

I'm sure this will seem obvious to some people, but I still think the current methodology is flawed.
 [2001-12-19 22:39 UTC] yohgaki@php.net
If you are using database and worry about cases like this, lock should be used. 
--
Yasuo Ohgaki
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 21:01:27 2024 UTC