On 11/21/03 Chris Devers wrote: >On Fri, 21 Nov 2003, Bruce Van Allen wrote: > >> My experience across about many different commercial and institutional >> web servers leads me to at minimum wrap up all system-related actions >> like file ops -- before printing output. And the best approach is: >> output last. Otherwise, I find webservers inconsistent as far as when >> they to let go of a CGI process. Perhaps someone who knows more about >> Apache or IIS could comment. > >I thought it was considered best to try to send back data early & often, >and to flush output by setting $| to 1 -- the idea being that a script >that takes a long time to produce results might lead to timeout errors >if >the web client gives up, but if you keep sending back data as it becomes >available then the client will tend to keep the connection open. > >Have I had this wrong?
Well, that's all correct. >Is it better to save up all output for the end? Most of my web apps have 100% dynamic output, and the main way I cope with timeout issues is to keep things fast. It could be that my experience is from particular combinations of web server, web browser, and my scripts' operations. Or maybe I've drawn a wrong conclusion. To be more specific, I noticed inconsistencies with some web apps that logged state & activity; if I waited to write to the logs after all http output was printed, my tests seemed to show that not every action was properly logged; if the actions were logged before final http output, no problems. If my logging routines involved time-consuming things like looking up and manipulating data, especially over a network, things would get worse. I always $|++, use strict, check return values, and I test relentlessly. The inconsistent results lead me to conclude that factors outside my control were causing the web server to sometimes drop or ignore the trailing parts of my scripts after printing output. "Inconsistent" means I don't see the pattern, not that there isn't one. Thinking about it, another reason I habitually delay printing even http headers is that a script's result state might be expressed as a redirect, an image, or as plain text, rather than html. OTOH, a quick look shows that I have a bunch of CGIs deployed whose first action is to print the usual "Content-type: text/html\n\n" line, long before doing anything with the input or any data, which follows the standard CGI advice. So, no, Chris, you're not wrong. But my "what works" practice is to do as much as possible before output. Maybe it's more correct to say "before final output" but I don't know how the webserver would know that a script has no more output. Is it because the client breaks the connection once it gets the html output? Again, perhaps someone who understand more about how Apache (or IIS) controls CGI execution could comment. - Bruce __bruce__van_allen__santa_cruz__ca__
