Re: Using 'header' as redirect

Philip Thompson wrote:

On May 30, 2006, at 12:52 PM, Stut wrote:

Philip Thompson wrote:

Ok, I have modified my code a little bit. Stut, yes, output buffering was on by default (4096). I *think* this will work. It appears to be the same as before - still redirecting appropriately: <!-- index.php --> <? ob_start(); ?> <html> <head>...</head> <body> <? include ($subPage); ob_end_flush(); ?> </body> The subpage does not change any, only index.php. I am basically "holding off" on displaying the stuff between ob_start() and ob_end_flush(), unless it's header information. That way, if the subpage needs to redirect, it can without errors. Correct?

Indeed. Output buffering does exactly what it says on the tin - it buffers the output until the page execution finishes or it's explicitly flushed. Your ob_end_flush call is technically not needed unless you have a reason to end the buffering at that point. -Stut

I was under the impression that if ob_end_flush() was not called, then there would be a memory leak. Is this not the case? From http://us3.php.net/ob_start : "Output buffers are stackable, that is, you may call ob_start() while another ob_start() is active. Just make sure that you call ob_end_flush() the appropriate number of times. If multiple output callback functions are active, output is being filtered sequentially through each of them in nesting order." Also 4096k... I wonder if that's enough buffering to include all the stuff that I want to show? As of right now, it is. Is there another standard level of buffering to specify? ~PT

Browsers usually choke on that kind of volume of HTML (Well, choke as in take forever to load a page while sucking up massive amounts of system memory)... Not to mention there are very few situations where you actually need to output 4MB of HTML in a single page load. I'd say that if you're worried about overrunning PHP's output buffers, you have more serious design issues with your script. In itself, it isn't a memory leak; PHP always flushes all buffers when a script terminates. AFAIK this is the default behavior with output buffering enabled; PHP buffers all script output and then flushes it when the script terminates. I have no idea if PHP is smart enough to flush the buffer if it fills up. But seriously, this shouldn't be an issue; break your data up into more manageable chunks so that you aren't trying to cram 4MB of HTML into some poor user's browser. If you're getting this data from a database, set a limit to how many records can be shown, and give the user a form to control the parameters of what data is returned. Regards, Adam Zey.