Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
PHP does not flush output on IIS7 ..
828 views
Skip to first unread message
brill...@gmail.com
Jul 10, 2012, 6:53:50 AM7/10/12
to
The following PHP program was flushing output correctly on an old Win2000 server with IIS 5.x - but refuses to do the same on a Windows 2008 64 bits server running IIS7.
Rather than throwing a line on the browser every second as coded, it waits the entire loop, buffers the result, and prints all at once when the code ends running.
Rather than throwing a line on the browser every second as coded, it waits the entire loop, buffers the result, and prints all at once when the code ends running.
brill...@gmail.com
Jul 10, 2012, 7:06:56 AM7/10/12
to
header("Content-Type: text/html; charset=utf-8");
function flush_buffers(){
ob_end_flush();
ob_flush();
flush();
ob_start();
}
ob_start();
flush_buffers();
echo "starting...<br/>\n";
for($i = 0; $i < 3; $i++) {
flush_buffers();
print "$i<br/>\n";
flush_buffers();
sleep(2);
}
flush_buffers();
print "DONE!<br/>\n";
$myFile = "test.php";
$fh = fopen($myFile, 'r');
$source = fread($fh, filesize($myFile));
$source = htmlspecialchars($source);
print "<p><hr>Here is the code of this program:<pre>\n";
echo $source;
flush()
function flush_buffers(){
ob_end_flush();
ob_flush();
flush();
ob_start();
}
ob_start();
flush_buffers();
echo "starting...<br/>\n";
for($i = 0; $i < 3; $i++) {
flush_buffers();
print "$i<br/>\n";
flush_buffers();
sleep(2);
}
flush_buffers();
print "DONE!<br/>\n";
$myFile = "test.php";
$fh = fopen($myFile, 'r');
$source = fread($fh, filesize($myFile));
$source = htmlspecialchars($source);
print "<p><hr>Here is the code of this program:<pre>\n";
echo $source;
flush()
brill...@gmail.com
Jul 10, 2012, 7:02:52 AM7/10/12
to
On Tuesday, July 10, 2012 12:53:50 PM UTC+2, (unknown) wrote:
> The following PHP program was flushing output correctly on an old Win2000 server with IIS 5.x - but refuses to do the same on a Windows 2008 64 bits server running IIS7.
>
> Rather than throwing a line on the browser every second as coded, it waits the entire loop, buffers the result, and prints all at once when the code ends running.
> The following PHP program was flushing output correctly on an old Win2000 server with IIS 5.x - but refuses to do the same on a Windows 2008 64 bits server running IIS7.
>
> Rather than throwing a line on the browser every second as coded, it waits the entire loop, buffers the result, and prints all at once when the code ends running.
Erwin Moller
Jul 10, 2012, 7:23:20 AM7/10/12
to
On 7/10/2012 12:53 PM, brill...@gmail.com wrote:
> The following PHP program was flushing output correctly on an old Win2000 server with IIS 5.x - but refuses to do the same on a Windows 2008 64 bits server running IIS7.
>
> Rather than throwing a line on the browser every second as coded, it waits the entire loop, buffers the result, and prints all at once when the code ends running.
>
You forgot to post the "following PHP program".
> The following PHP program was flushing output correctly on an old Win2000 server with IIS 5.x - but refuses to do the same on a Windows 2008 64 bits server running IIS7.
>
> Rather than throwing a line on the browser every second as coded, it waits the entire loop, buffers the result, and prints all at once when the code ends running.
>
A few ideas:
1) It is very well possible your webserver (IIS7) decided to buffer the
results until it deemed the output worthy (big enough) to send to the
client.
2) Behaviour depends also on the way you installed PHP
(CGI/fast-cgi/isapi/more?)
3) Did you check php.ini? Maybe you are using output buffering without
knowing.
4) If you really need such behavior, you better ask in an IIS related
newsgroup.
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
brill...@gmail.com
Jul 10, 2012, 9:42:01 AM7/10/12
to
On Tuesday, July 10, 2012 1:23:20 PM UTC+2, Erwin Moller wrote:
> On 7/10/2012 12:53 PM, David wrote:
> You forgot to post the "following PHP program".
I did post it .. some timing issue I guess. It is there above your post.
> A few ideas:
> 1) It is very well possible your webserver (IIS7) decided to buffer the
> results until it deemed the output worthy (big enough) to send to the
> client.
OK, I understand that and am looking for whatever implicit setting forces the buffering.
> 2) Behaviour depends also on the way you installed PHP
> (CGI/fast-cgi/isapi/more?)
It is a default installation of PHP for IIS from Microsoft, and I do see that it uses the FastCGI - the IIS FastCGI settings do contain the path of the php-cgi.exe.
> 3) Did you check php.ini? Maybe you are using output buffering without
> knowing.
I do see the php.ini file under C:\Program File...\PHP\v5.3.
Cannot edit it .. it says read only.
Is it normal to edit these files manually?
Or does the PHP5.x provide a GUI for doing such things in a more controlled way?
> 4) If you really need such behavior, you better ask in an IIS related
> newsgroup.
Good point, will look for an IIS related newsgroup.
> On 7/10/2012 12:53 PM, David wrote:
> You forgot to post the "following PHP program".
I did post it .. some timing issue I guess. It is there above your post.
> A few ideas:
> 1) It is very well possible your webserver (IIS7) decided to buffer the
> results until it deemed the output worthy (big enough) to send to the
> client.
> 2) Behaviour depends also on the way you installed PHP
> (CGI/fast-cgi/isapi/more?)
> 3) Did you check php.ini? Maybe you are using output buffering without
> knowing.
Cannot edit it .. it says read only.
Is it normal to edit these files manually?
Or does the PHP5.x provide a GUI for doing such things in a more controlled way?
> 4) If you really need such behavior, you better ask in an IIS related
> newsgroup.
Robert Heller
Jul 10, 2012, 11:38:02 AM7/10/12
to
At Tue, 10 Jul 2012 06:42:01 -0700 (PDT) brill...@gmail.com wrote:
>
> On Tuesday, July 10, 2012 1:23:20 PM UTC+2, Erwin Moller wrote:
> > On 7/10/2012 12:53 PM, David wrote:
> > You forgot to post the "following PHP program".
>
> I did post it .. some timing issue I guess. It is there above your post.
>
> > A few ideas:
> > 1) It is very well possible your webserver (IIS7) decided to buffer the
> > results until it deemed the output worthy (big enough) to send to the
> > client.
>
> OK, I understand that and am looking for whatever implicit setting forces the buffering.
>
> > 2) Behaviour depends also on the way you installed PHP
> > (CGI/fast-cgi/isapi/more?)
>
> It is a default installation of PHP for IIS from Microsoft, and I do see that it uses the FastCGI - the IIS FastCGI settings do contain the path of the php-cgi.exe.
>
> > 3) Did you check php.ini? Maybe you are using output buffering without
> > knowing.
>
> I do see the php.ini file under C:\Program File...\PHP\v5.3.
> Cannot edit it .. it says read only.
> Is it normal to edit these files manually?
Yep -- it is the UNIX way. It is a plain text file. I am guessing the
>
> On Tuesday, July 10, 2012 1:23:20 PM UTC+2, Erwin Moller wrote:
> > On 7/10/2012 12:53 PM, David wrote:
> > You forgot to post the "following PHP program".
>
> I did post it .. some timing issue I guess. It is there above your post.
>
> > A few ideas:
> > 1) It is very well possible your webserver (IIS7) decided to buffer the
> > results until it deemed the output worthy (big enough) to send to the
> > client.
>
> OK, I understand that and am looking for whatever implicit setting forces the buffering.
>
> > 2) Behaviour depends also on the way you installed PHP
> > (CGI/fast-cgi/isapi/more?)
>
> It is a default installation of PHP for IIS from Microsoft, and I do see that it uses the FastCGI - the IIS FastCGI settings do contain the path of the php-cgi.exe.
>
> > 3) Did you check php.ini? Maybe you are using output buffering without
> > knowing.
>
> I do see the php.ini file under C:\Program File...\PHP\v5.3.
> Cannot edit it .. it says read only.
> Is it normal to edit these files manually?
file is owned by an Admin account and you are not logged in as an
Admin. Or something like that.
> Or does the PHP5.x provide a GUI for doing such things in a more controlled way?
phpadmin (not actually part of PHP5.x, but a separate package) might.
>
> > 4) If you really need such behavior, you better ask in an IIS related
> > newsgroup.
>
> Good point, will look for an IIS related newsgroup.
>
Robert Heller -- 978-544-6933 / hel...@deepsoft.com
Deepwoods Software -- http://www.deepsoft.com/
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
Jerry Stuckle
Jul 10, 2012, 11:47:10 AM7/10/12
to
On 7/10/2012 6:53 AM, brill...@gmail.com wrote:
> The following PHP program was flushing output correctly on an old Win2000 server with IIS 5.x - but refuses to do the same on a Windows 2008 64 bits server running IIS7.
>
> Rather than throwing a line on the browser every second as coded, it waits the entire loop, buffers the result, and prints all at once when the code ends running.
>
Not unusual. All the PHP flush() can do is flush the PHP buffers.
> The following PHP program was flushing output correctly on an old Win2000 server with IIS 5.x - but refuses to do the same on a Windows 2008 64 bits server running IIS7.
>
> Rather than throwing a line on the browser every second as coded, it waits the entire loop, buffers the result, and prints all at once when the code ends running.
>
These are sent to the web server, which may do buffering of its own.
It could also be buffered between the web server and the client
application (i.e. server's OS, routers along the way, client OS), but
these are generally very short time and can *usually* be ignored.
When it finally gets to the client, the browser may display the data
immediately, or it may buffer it until some or all of the data comes in
(i.e. HTML tables are often buffered).
All PHP can control is the initial PHP buffers. Everything else is
beyond its control. Since the only thing you changed was your IIS, I
would suggest you look at IIS to see if there's a way to do what you want.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================
brill...@gmail.com
Jul 11, 2012, 10:00:26 AM7/11/12
to
Solution found ..
In the end it is IIS, but it is specific for Perl too.
One needs to find the web.config file inside the folder where the script sits, edit it, and at the end of the tag containing the handler for *.pl or *.cgi, add a tag for responseBufferLimit="0", to achieve something like this:
<add name="Perl CGI for .cgi" path="*.cgi" verb="*" modules="CgiModule" scriptProcessor="C:\Perl64\bin\perl.exe "%s" %s" resourceType="Unspecified" requireAccess="Script" preCondition="bitness64" responseBufferLimit="0"/>
<add name="Perl CGI for .pl" path="*.pl" verb="*" modules="CgiModule" scriptProcessor="C:\Perl64\bin\perl.exe "%s" %s" resourceType="Unspecified" requireAccess="Script" responseBufferLimit="0"/>
PHP has a different solution.
In the end it is IIS, but it is specific for Perl too.
One needs to find the web.config file inside the folder where the script sits, edit it, and at the end of the tag containing the handler for *.pl or *.cgi, add a tag for responseBufferLimit="0", to achieve something like this:
<add name="Perl CGI for .cgi" path="*.cgi" verb="*" modules="CgiModule" scriptProcessor="C:\Perl64\bin\perl.exe "%s" %s" resourceType="Unspecified" requireAccess="Script" preCondition="bitness64" responseBufferLimit="0"/>
<add name="Perl CGI for .pl" path="*.pl" verb="*" modules="CgiModule" scriptProcessor="C:\Perl64\bin\perl.exe "%s" %s" resourceType="Unspecified" requireAccess="Script" responseBufferLimit="0"/>
PHP has a different solution.
Captain Paralytic
Jul 12, 2012, 5:18:22 AM7/12/12
to
solution for Perl.
0 new messages