session_write_close

(PHP 4 >= 4.0.4, PHP 5, PHP 7)

session_write_close — Write session data and end session

Descrierea

voidsession_write_close
( void
)

End the current session and store session data.

Session data is usually stored after your script terminated without the
need to call session_write_close(), but as session data
is locked to prevent concurrent writes only one script may operate on a
session at any time. When using framesets together with sessions you will
experience the frames loading one by one due to this locking. You can
reduce the time needed to load all the frames by ending the session as
soon as all changes to session variables are done.

Valorile întoarse

Nu este întoarsă nici o valoare.

A se vedea și

User Contributed Notes 25 notes

You can have interesting fun debugging anything with sleep() in it if you have a session still active. For example, a page that makes an ajax request, where the ajax request polls a server-side event (and may not return immediately).

If the ajax function doesn't do session_write_close(), then your outer page will appear to hang, and opening other pages in new tabs will also stall.

An easy gotcha here - the $_SESSIONS superglobal does not vanish because you call session_write_close. If subsequent to the write_close call if you manipulate the superglobal the changes will not be saved when the script exists. Likewise a call to session_regenrate_id will fail.

Closing the session and then manipulating session variables is not something many would do by intent. However, if your sessions suddenly start misbehaving, failing to record changes etc it is well worth checking that the cause is not this one!

I found with one PHP login system that even session_write_close() was not setting the session variables before I transferred pages with a Location: header. So the user would log in, I would create the $_SESSION variables, call session_write_close() and then transfer to the secure page using header(Location:...). The secure page would check for the session vars, not find them, and force the user to log in again. After the second login the session would be found and they could continue.

My workaround was to create the $_SESSION variables with 0 values before writing the initial login page. Then I updated the session vars with the login results and used the header() function to switch to the secure location. Once the session vars have already been created, updated values are assigned quickly. Problem solved. Just be sure the secure page checks both that the $_SESSION var exists AND that it's not 0.

As we all know, if an object is serialised, then the class definition must be included _before_ it is unserialised.

My framework has an enormous number of class files, and including them all at the beginning of the script was really taking it's toll on my system (memory and execution time) so I switched to including required classes at the top of each class file that used them using require_once.

This caused problems because I start my session at the very beginning of my script's execution, but all my class files aren't there at the beginning!!

Further to the comment by nakanishi at mailstyle dot com, it appears that calling session_write_close() followed by session_start() causes issues if you have more than one browser window/tab open in the session, and have a large session data array. I have an intermitent (and hard to replicate reliably) issue with session_start() never being called or not returning - the script hangs before the session headers are written. I'm puting this down to trying to be too clever rather than to a bug per se.

If you're saving data to a session but finding it's not actually being saved, check and ensure that you're not assigning any arrays with a key containing the pipe character (|). This will prevent the session data from being serialized and saved.

I had a problem with realizing the restore password form. First a user entered his login or e-mail in the system.

Then the script searched the database, got the session data, and sended link with SID to registered e-mail. The link was configured so, that it restored session data and logged user in the secure interface to the change password form.

Then was displayed a page with the message about sended message.

The problem was that ID was not unique in three pages, the SID sended to e-mail anyone could see in cookie.

I tryed to start new session before generating and after sending link with the code:

The trouble was that SID was the same even after session_unlink() and session_write_close(). The session_start() function just restored the previous session data!!! So the script was not safe. Then I added session_regenerate_id() call after each session_start().

And now it works as needed! The SID sending to user we cannot see in cookies nor before neither after generated link, but the data is saved in session with this id. So only the owner of account can get it!

If You apply session_write_close() to allow concurrent requests from a client (for example simultaneous AJAX calls) this may not resolve the problem, if You have enabled output buffering (default in PHP 7+). You have to set output_buffering = Off in php.ini, otherwise session won't be closed immediately.

You can easily make a cool chatbox without using frames and subdomains in combination with SSE (server side events), using for example a 'while(true){sleep($x)}' loop..

Using session_write_close() prevents the session being locked (because the request 'never' ends (maybe after a minute or two.. but otherwise the page would hang).

So you can make a chatbox without shell access on shared hosting, you just need to make a 'output all clients the new messages' function for the SSE stream and code a few lines of javascript. Read up on SSE.

Obviously need a good caching or fast database with a lot of clients, because everyone will spawn a new stream connection. (in contrast to push mechanisms which will require at least a cron job on shared hosting).

For the session problem when using header("Location:..."), I found session_write_close() not to help me on the my IIS server using PHP in CGI mode. The problem was the PHPSESSID cookie was never being set, so I did it the manual way:

This function is useful for forcing serialization of session data but it can introduce difficult-to-track bugs if it's called more than once per session_start() call. Since it doesn't have a return value or raise an exception there won't be any indication that the serialization failed and the code will continue normally. Only when a user visits a page that depends on unsaved session data will there be any indication of the failure.As far as I can tell this affects both the default and custom session handling functions.

if you are trying to work with a larger code base meant for a specific application... and it implements some custom session save handlers, it appears there is no way to reset those save handlers back to the default php state if they are getting in your way. my workaround:

Remember: objects with private and/or protected data members cannot be serialized properly by PHP. If you ever find that you are missing some objects from your $_SESSION, make sure you are accounting for this shortcoming in your application.

Along the same lines as what cenaculo at netcabo dot pt, bkatz at usefulengineering dot com, and editorial at literati dot ca said about making sure you session_write_close(), don't forget to ob_end_flush() if you're using output buffering.

I've been having some weird hanging issues when I tried to navigate away from a page with content streaming in an Iframe or a separate window.

session_write_close() worked as a lifesaver for me when automatically uploading files to a user (forcing a download instead of a link). If files are large, and since session_start() does not allow another page using session_start() to proceed until it's done, i was not able to upload more than one file at a time. By using session_write_close() before beginning the file upload, my users can now download as many big files as they like, at the same time. Example:

I was having the same problem as many here regarding setting session data just before a header location redirect and having the session data just not be there. I tried everything people here said, and none of their combinations worked. What did finally work for me was to fire off a session_regenerate_id(true) call just prior to the header() and die() calls.

session_regenerate_id(true);header('location: blah blah');die();

Without the regenerate id call, the write close did not seem to do anything. session_write_close() doesn't seem to matter at all. It certainly didn't fix anything on its own for me.

This is a rather annoying issue with php sessions that I've never run into before. I store my sessions to /dev/shm (which is RAM) so file IO blocking can't be the problem. Now I'm nervous that some other session data might not be getting updated prior to a header() location change, which is extremely important and common in any web app.

Using a SQL Server database and Windows Server 2003, if you use session_write_close() prior to a header() call, and it still appears to freeze up your session, check to make sure that you are not in the middle of a transaction.

I noticed that by starting a transaction, executing some queries, attempting to write close the session and then redirecting without rolling back or committing that transaction, your session may freeze up. Just like what you may experience if you attempt to redirect with header() without first calling session_write_close().