(PHP 4 >= 4.0.4, PHP 5, PHP 7, PHP 8)
session_write_close — Записывает данные сессии и завершает её
Завершает текущую сессию и сохраняет её данные.
Данные сессии обычно сохраняются после завершения выполнения скрипта без необходимости вызова session_write_close(). Поскольку данные сессии заблокированы для предотвращения одновременной конкурирующей записи, только один скрипт может работать с сессией в любой момент времени. Из-за этой блокировки, при использовании фреймов вместе с сессиями, фреймы будут загружаться по очереди один за одним. Можно уменьшить время загрузки всех фреймов путём завершения сессии сразу, как только будут выполнены все необходимые изменения переменных сессии.
У этой функции нет параметров.
Функция возвращает true, если выполнилась успешно, или false, если возникла ошибка.
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!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.Why this function is highly important? I explain.
In a nutshell, how session works:
Client side: php is sending back to the client, a cookie with the id of the session. So, the session ends when the server ends to process the script and not when session_write_close() is executed. So, using session_write_close() for fast saving the session in the client side is useless unless you are ob_flush() and flush() to the customer.
Server side: It could be changed but the normal behavior is to save the session information in a file. For example:
sess_b2dbfc9ddd789d66da84bf57a62e2000 file
**This file is usually locked**, so if two sessions are trying open at the same time, then one is freezed until the file is unlocked. session_write_close() ends the lock.
For example:
<?php
$t1=microtime(true);
session_start();
sleep(3);
session_write_close();
$t2=microtime(true);
echo $t2-$t1;
?>
If we run this code in two processes (using the same session, such as two tabs), then one will return 3 seconds while the other will return 6 seconds.
Its caused because the first process lock the session file.
However, changing to:
<?php
$t1=microtime(true);
session_start();
session_write_close();
sleep(3);
$t2=microtime(true);
echo $t2-$t1;
?>
both files runs at 3 seconds.
For PHP 7.0 and higher, we could use session_start(true); for auto close after the first read.
This operation is highly important for AJAX when we used to do many operations in parallel by using the the same sessionWorkaround if session_write_close() still doesn't write sessions fast enough:
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.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 have been using a mysql database custom session handler (not using cookies) and was having problems getting the session data to be saved consistantly on my database driven website
clients also have to navigate across domains for website management at times so i have some special code to make all this happen relatively seamlessly and to ensure that each person's data is secure.
i added session_write_close() at the very end of the last script that set session data and solved the problem.
i am not sure why, but it seems the calls to write and close were not always being made (i was not smart enough to figure it out)
now that the session_write_close() call is being made, my problems seemed to have disappeared - hopefully for good.
hope this helps someone.i had trouble with 2 concurrent scripts, a login form with a php generated captcha... the latter truncated the session (session file length 0) so the login always failed due token or captcha error... i thought that was a session blocking problem, but was not
<?php // pseudo code
@session_start();
$_SESSION['token'] = $token = random_string();
session_write_close();
?><pseudo html>
<form>
<hidden $token/>
Name : <input name/>
Pass : <input pass/>
Captcha <img captcha.php/> : <input captcha/>
<submit/>
</form>
</html>
<?php // captcha.php pseudo code
$code = random_string();
if ( request_valid() )
{
@session_start();
$_SESSION['captcha|'.$HTTP_REFERER] = $code;
session_write_close();
}
$img = text_to_img($code);
send_img($img);
?>
i choose pipeline as separator in line $_SESSION['captcha|'.$HTTP_REFERER] = $code; because being forbidden in urls "<>[\]^`{|}space
but seems pipeline produced serialization errors on session file, so changing to another inocuous character (underscode in my case) solved the problem... try to avoid reserved serialization characters |:{}";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).
Cheap chatbox.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:
<?php ....
session_start();
/*Getting user login and e-mail from database*/
$user_login = "....";
$user_id = "....."
/*CLOSE PREVIOUS SESSION*/
session_unlink();
session_destroy();
/*NOW GENERATING LINK FOR SESSION DATA */
session_start();
$_SESSION = $user_login;
$_SESSION = $user_id;
/*here generating link:*/
$link = "http://host.com/restore=" . SID . "";
mail (....);
/*CLOSE THE SESSION WITH USER DATA*/
session_write_close();
/*AND STARTING A NEW SESSION*/
session_start();
/*THEN LOAD THE 'MESSAGE SENDED' PAGE*/
header("Location: /restore/message_sended/");
?>
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().
<?php ....
session_start();
/*Getting user login and e-mail from database*/
$user_login = "....";
$user_id = "....."
/*CLOSE PREVIOUS SESSION*/
session_unlink();
session_destroy();
/*NOW GENERATING LINK FOR SESSION DATA */
session_start();
session_regenerate_id();//Regenerating SID for sending
$_SESSION = $user_login;
$_SESSION = $user_id;
/*here generating link:*/
$link = "http://host.com/restore=" . SID . "";
mail (....);
/*CLOSE THE SESSION WITH USER DATA*/
session_write_close();
/*AND STARTING ANOTHER NEW SESSION*/
session_start();
session_regenerate_id(); //Regenerating SID
/*THEN LOAD THE 'MESSAGE SENDED' PAGE*/
header("Location: /restore/message_sended/");
?>
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!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.Beware, if you overwrite the default PHP Session handling and use debugging code inside the write() function, the debugging code is not executed until you run session_write_close().
I tried everything, file logging directly from the write() function, global debugging variable increments, static class properties. The only things written were the session open() and read() calls. My debugging code looks like this:
<?php
$Session = new Session();
...
class Session() {
public function write($id)
$sql = "UPDATE ... WHERE id=". mysql_real_escape_string($id);
self::$debug_Info .= "session_write sql=$sql";
...
}
# then at the very end of the script:
# session debugging
session_write_close();
error_log($Session->getDebugInfo(), 3, 'logs/sessions.log');
?>
where getDebugInfo simply returns self::$debug_Info. Without session_write_close() the sessions.log would only contain the open() and read() calls.
Maybe intuitive to many, it took days to realize. hope it helps!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!!
So no in my special 'require' function, I do the following:
if(!class_exists($to_require))
{
session_write_close();
require_once('path/to/classes/'.$to_require.'.php');
session_start();
}
This is a considerably smaller performance hit that including every class that the application uses at the very beginning of the application.