[PHP-DOC] #24295 [Opn]: Sessions that pass documents back using fpassthru hang intermittently
ID: 24295 User updated by: marcus at quintic dot co dot uk Reported By: marcus at quintic dot co dot uk Status: Open Bug Type: Documentation problem Operating System: Windows XP PHP Version: 4.3.2 New Comment: Eh? I realise the session file should be locked to restrict access, what I dont expect is the browser to lockup completely. If any of the pages are requested/executed at the same time then surely each of the frames should just go about their business, wait for the session file lock to come free and continue to work. Whilst this may delay some of the documents it shouldnt be significant. It certainly shouldnt lock up the browser completely. Previous Comments: [2003-06-23 06:03:30] [EMAIL PROTECTED] This is actually expected. The session module will lock the file so that seperate processes can not write to it at the same time and mess the files up. This should be documented better though. (I remember there was a report on this before in which Sascha added a much better explanation). [2003-06-23 05:47:57] marcus at quintic dot co dot uk Description: I have an application that uses multiple frames (anywhere from 5-10 at a time). The frames get updated at roughly the same time - a user steps through a flowchart that has multiple documents attached to each step that can target any of the frames). Each of the frames is running in the same session (in that the php that generates a requested page starts with session_start()). The document to be displayed is passed through on the url and this argument is looked up in an array which returns a path to a local file. This path is then fed to fpassthru and the document gets served up to the browser. The session locks up randomly using fpassthru, but if the fpassthru is replaced by a redirect (header(Location:)) to a web based copy of the requested document the lock up stop occuring. Obviously the workaround is to use the redirect but this means that a user can get directly to a document without going through the session authentication etc, so I'd prefer to get the fpassthru to work. My php installation is the standard install with the following extensions enabled: extension=php_db.dll extension=php_dba.dll extension=php_dbx.dll extension=php_domxml.dll extension=php_gd2.dll extension=php_mhash.dll extension=php_pdf.dll extension=php_shmop.dll extension=php_sockets.dll extension=php_xmlrpc.dll I'm using the SAPI module. The problem still exists (although seems to happen less frequently) with the cgi version. Reproduce code: --- start_session(); // lookup file and place in $path // ... code removed ... // send headers header(Pragma: ); header(Cache-Control: ); // lookup mimetype and place in $mimetype // ... code removed ... header(Content-type: . $mimetype ); $sizeh = Content-length: . filesize($path); header($sizeh); header(Content-transfer-encoding: binary\n); // send file contents $fp=fopen($path, rb); fpassthru($fp); fclose($fp); exit; Expected result: The document requested in the browser frame, which is what happens the majority of times (approx 95%). Its definitely something to do with an interaction between a session and fpassthru because removing either fixes the problem. Actual result: -- Lockups approx 5% of the time - a new session can be started in a different browser instance, but the current session is lost. -- Edit this bug report at http://bugs.php.net/?id=24295edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #24295 [Opn]: Sessions that pass documents back using fpassthru hang intermittently
ID: 24295 User updated by: marcus at quintic dot co dot uk Reported By: marcus at quintic dot co dot uk Status: Open Bug Type: Documentation problem Operating System: Windows XP PHP Version: 4.3.2 New Comment: Mmmm - I may not have made myself clear enough in the bug report! By lockups I meant that the _whole_ session locks completely and never comes back to life. Once a frame gets into this state, none of the other frames will work and the browser appears to be completely locked up. A new instance of the browser works as normal though (different session). Previous Comments: [2003-06-23 06:11:42] marcus at quintic dot co dot uk Eh? I realise the session file should be locked to restrict access, what I dont expect is the browser to lockup completely. If any of the pages are requested/executed at the same time then surely each of the frames should just go about their business, wait for the session file lock to come free and continue to work. Whilst this may delay some of the documents it shouldnt be significant. It certainly shouldnt lock up the browser completely. [2003-06-23 06:03:30] [EMAIL PROTECTED] This is actually expected. The session module will lock the file so that seperate processes can not write to it at the same time and mess the files up. This should be documented better though. (I remember there was a report on this before in which Sascha added a much better explanation). [2003-06-23 05:47:57] marcus at quintic dot co dot uk Description: I have an application that uses multiple frames (anywhere from 5-10 at a time). The frames get updated at roughly the same time - a user steps through a flowchart that has multiple documents attached to each step that can target any of the frames). Each of the frames is running in the same session (in that the php that generates a requested page starts with session_start()). The document to be displayed is passed through on the url and this argument is looked up in an array which returns a path to a local file. This path is then fed to fpassthru and the document gets served up to the browser. The session locks up randomly using fpassthru, but if the fpassthru is replaced by a redirect (header(Location:)) to a web based copy of the requested document the lock up stop occuring. Obviously the workaround is to use the redirect but this means that a user can get directly to a document without going through the session authentication etc, so I'd prefer to get the fpassthru to work. My php installation is the standard install with the following extensions enabled: extension=php_db.dll extension=php_dba.dll extension=php_dbx.dll extension=php_domxml.dll extension=php_gd2.dll extension=php_mhash.dll extension=php_pdf.dll extension=php_shmop.dll extension=php_sockets.dll extension=php_xmlrpc.dll I'm using the SAPI module. The problem still exists (although seems to happen less frequently) with the cgi version. Reproduce code: --- start_session(); // lookup file and place in $path // ... code removed ... // send headers header(Pragma: ); header(Cache-Control: ); // lookup mimetype and place in $mimetype // ... code removed ... header(Content-type: . $mimetype ); $sizeh = Content-length: . filesize($path); header($sizeh); header(Content-transfer-encoding: binary\n); // send file contents $fp=fopen($path, rb); fpassthru($fp); fclose($fp); exit; Expected result: The document requested in the browser frame, which is what happens the majority of times (approx 95%). Its definitely something to do with an interaction between a session and fpassthru because removing either fixes the problem. Actual result: -- Lockups approx 5% of the time - a new session can be started in a different browser instance, but the current session is lost. -- Edit this bug report at http://bugs.php.net/?id=24295edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #24295 [Opn]: Sessions that pass documents back using fpassthru hang intermittently
ID: 24295 User updated by: marcus at quintic dot co dot uk Reported By: marcus at quintic dot co dot uk Status: Open Bug Type: Documentation problem Operating System: Windows XP PHP Version: 4.3.2 New Comment: wrt disabling session.enable_trans_sid Assuming you mean the use_trans_sid option, its already disabled. Previous Comments: [2003-06-23 06:56:53] [EMAIL PROTECTED] Disable session.enable_trans_sid in php.ini or by Files filename.php-Entry in http.conf and see if your problem is gone. [2003-06-23 06:16:19] marcus at quintic dot co dot uk Mmmm - I may not have made myself clear enough in the bug report! By lockups I meant that the _whole_ session locks completely and never comes back to life. Once a frame gets into this state, none of the other frames will work and the browser appears to be completely locked up. A new instance of the browser works as normal though (different session). [2003-06-23 06:11:42] marcus at quintic dot co dot uk Eh? I realise the session file should be locked to restrict access, what I dont expect is the browser to lockup completely. If any of the pages are requested/executed at the same time then surely each of the frames should just go about their business, wait for the session file lock to come free and continue to work. Whilst this may delay some of the documents it shouldnt be significant. It certainly shouldnt lock up the browser completely. [2003-06-23 06:03:30] [EMAIL PROTECTED] This is actually expected. The session module will lock the file so that seperate processes can not write to it at the same time and mess the files up. This should be documented better though. (I remember there was a report on this before in which Sascha added a much better explanation). [2003-06-23 05:47:57] marcus at quintic dot co dot uk Description: I have an application that uses multiple frames (anywhere from 5-10 at a time). The frames get updated at roughly the same time - a user steps through a flowchart that has multiple documents attached to each step that can target any of the frames). Each of the frames is running in the same session (in that the php that generates a requested page starts with session_start()). The document to be displayed is passed through on the url and this argument is looked up in an array which returns a path to a local file. This path is then fed to fpassthru and the document gets served up to the browser. The session locks up randomly using fpassthru, but if the fpassthru is replaced by a redirect (header(Location:)) to a web based copy of the requested document the lock up stop occuring. Obviously the workaround is to use the redirect but this means that a user can get directly to a document without going through the session authentication etc, so I'd prefer to get the fpassthru to work. My php installation is the standard install with the following extensions enabled: extension=php_db.dll extension=php_dba.dll extension=php_dbx.dll extension=php_domxml.dll extension=php_gd2.dll extension=php_mhash.dll extension=php_pdf.dll extension=php_shmop.dll extension=php_sockets.dll extension=php_xmlrpc.dll I'm using the SAPI module. The problem still exists (although seems to happen less frequently) with the cgi version. Reproduce code: --- start_session(); // lookup file and place in $path // ... code removed ... // send headers header(Pragma: ); header(Cache-Control: ); // lookup mimetype and place in $mimetype // ... code removed ... header(Content-type: . $mimetype ); $sizeh = Content-length: . filesize($path); header($sizeh); header(Content-transfer-encoding: binary\n); // send file contents $fp=fopen($path, rb); fpassthru($fp); fclose($fp); exit; Expected result: The document requested in the browser frame, which is what happens the majority of times (approx 95%). Its definitely something to do with an interaction between a session and fpassthru because removing either fixes the problem. Actual result: -- Lockups approx 5% of the time - a new session can be started in a different browser instance, but the current session is lost. -- Edit this bug report at http://bugs.php.net/?id=24295edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
