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

go to bug id or search bugs for

Bug #36076 Memory before HTTP response
Submitted: 2006-01-19 01:51 UTC Modified: 2006-01-19 22:54 UTC
From: brian at blueo2 dot com Assigned:
Status: Not a bug Package: HTTP related
PHP Version: 5.1.2 OS: FreeBSD 5.4,6.0,amd64
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: brian at blueo2 dot com
New email:
PHP Version: OS:

 

 [2006-01-19 01:51 UTC] brian at blueo2 dot com 
Description:
------------
1) Loading several URLS that are running fread operations and displaying the binary output to the browser
2) While those URLs are still processing (using a Flash app), redirect through a <a href> link to another PHP pahe
3) Data is presented before the HTTP/1.1 response header from a previous request.

Reproduce code:
---------------
<?php
$fp = fopen('/dev/zero', 'ro');
while ($d = fread($fp, 1024))
{
  echo $d;
  flush();
}
?>

Expected result:
----------------
Not getting the results from previous requests before HTTP headers.  

Actual result:
--------------
Data from previous request before HTTP/1.1 200 OK and additional headers.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-01-19 04:10 UTC] brian at blueo2 dot com 
I am trying to get a single script that will display this particular issue, but so far, the only way I have been able to reproduce it reliably is with Flash loading a bunch of URLs in the background, and then clicking on a new page on the same server (such as the logo on the main page).

As an example of the behaviour, you can go to http://music.blueo2.com/?a=artist_Profile&cid=1, open up the song list, and play a bunch of the samples at the same time.  As they are playing, click on any other link on the site.  It is pretty easy to reproduce this way, but it doesn't happen with, say, only one other stream coming in.

I am thinking that this may be an issue with pipelining, but that is a complete stab in the dark.  I could try and get a tcpdump of the traffic, if that would help.  I will also try and make a single script which can replicate this issue.

I was thinking of re-assigning this to another category, as the problem really isn't with HTTP functions.  I mis-read the category list.  I don't know if this is an Apache2 issue or a scripting engine issue, or general web server issue.  It's basically the end of another request coming in on a new request before the HTTP/1.1 response header arrives.

I would be very happy to work with someone on a limited access account with access to our source to help find where the issue is, if there is some way we can work together.  We're completely strapped for cash, otherwise I would offer to pay someone for help.  I'll pay out-of-pocket a couple hundred for someone to track this down with me.  (Mountain View, Ca, US)
 [2006-01-19 07:27 UTC] brian at blueo2 dot com 
Okay, so I did a lot more digging around.  Extracted the important parts of the system, and it looks like the problem is either with PHP or Apache and the way it handles Keepalives.  It's not happening when I extract the basic componenets out, but ti's something deeper when it passes through our whole codebase.  (smarty, adodb, dbsessions)

This is the interesting part...  setting the "Connection: close" header before the script that dumps the sound sample fixes the issue.

If there's anything specifically I can do to help, please let me know.  I can't just post my companies codebase here, but I would love to help any way I can.  Someone could come by and look at the code if they wanted.

Cheers!

  -Brian

  -Brian
 [2006-01-19 08:10 UTC] sniper@php.net 
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
 [2006-01-19 22:51 UTC] brian at blueo2 dot com 
Since I have a workaround right now, I am not able to spend more time tracking down the initial bug.  We're not doing anything strange with semaphores or anything.  I would guess this is some sort of buffer issue with HTTP keepalives, but I am not sure what needs to happen to make the problem appear.  I know that passing the 'Connection: close' header does resolve the problem for me, but it doesn't mean the bug doesn't still exist.
 [2006-01-19 22:54 UTC] tony2001@php.net 
Feel free to reopen when you have a reproduce script to demonstrate the problem.
Until then -> bogus.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Oct 31 11:00:01 2025 UTC