php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #24295 Sessions that pass documents back using fpassthru hang intermittently
Submitted: 2003-06-23 05:47 UTC Modified: 2003-06-23 21:23 UTC
From: marcus at quintic dot co dot uk Assigned:
Status: Not a bug Package: Session related
PHP Version: 4.3.2 OS: Windows XP
Private report: No CVE-ID: None
View Developer Edit
 [2003-06-23 05:47 UTC] 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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-06-23 06:03 UTC] derick@php.net 
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 06:11 UTC] 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:16 UTC] 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:56 UTC] theseer@php.net 
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 07:58 UTC] marcus at quintic dot co dot uk 
wrt disabling session.enable_trans_sid 

Assuming you mean the use_trans_sid option, its already disabled.
 [2003-06-23 08:15 UTC] theseer@php.net 
Sorry, 'use_trans_sid' of course ( shoudln't have written the reply in a hurry..)

Whats the size of the files in question anyway?
Does it work more reliable with small(er) files?

I still don't the a documentation issue here..?
 [2003-06-23 08:33 UTC] marcus at quintic dot co dot uk 
File size seems not to matter - its a really annoying bug to try and reproduce as well. One day I'll have no problems at all, the next its falling over all the time. If I watch the apache logs there are no errors and once its locked no documents are being requested. If I switch on the php error logs nothing appears in there either. Is there anyway I can get more debug information? Its like a page is getting the session lock and not giving it up and so stopping all other pages from starting (because they all try to get the session).

Whats wierd is that nothing gets put in the apache access log - I can click on a button in one of the frames that launches a new window (using javascript) that I know requests a certain php document (again, under the same session), but the request never makes it into the access log and the document never gets to the window.

I think the original reply (after my submission) switched it to documentation - I've switched it back to session related.
 [2003-06-23 21:23 UTC] sniper@php.net 
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.

Thank you for your interest in PHP.


See bug: #22526
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Jul 16 14:01:33 2025 UTC