That's most likely due to buffering. There's nothing in the HTTP/CGI specs saying that content would have to be delivered/rendered immediately, before the request is finished. The webserver, some proxy, or the browser may be buffering... And browsers vary as to when they actually render content. Also, your CGI script itself may be buffering, because you're not flushing its output...

Further re almut's fine reply, "And browsers vary as to when they actually render content."

Further, the html elements matter. If, for example, your page is formatted using a <table>, <tr>, <td> structure, and you fail to provide width="..." specifications (or the css equivalent), your browser will HAVE TO WAIT for the </table> element to arrive in order to calculate the cell widths to use in rendering. Thus, no matter what you do at the server end, you won't be able to have your table render at intermediate stages.

In this narrow case, you can improve the chance that you'll get intermediate elements rendered, row-by-row, by spec'ing the width of each cell in the first row, be that a <tr> of <th> elements or a row of <td> elements. Note, however the operative phrase here is "improve the chance...."

Even doing so (which is a commonly accepted "Good Practice" for webmonkeys) won't overcome the other possible issues noted by almut and others.

Update: Fixed spelling of almut; closed code tag after 'width="...."'.

your browser will HAVE TO WAIT for the </table> element to arrive in order to calculate the cell widths to use in rendering.

I'm sure I've seen browsers render the table before it had fully arrived, and re-render the table as more info arrived. Of course, the browser is by no means obligated to do so.

Thanks for the prompt reply. I did a web search and came across the module CGI::Out. I'll see if that solves the problem. Thanks again!

...and came across the module CGI::Out

I've never used the module, but its description sounds like it's doing more or less the opposite of what you're trying to achieve. I.e. it's explicitly collecting/buffering any regular output from the script, in order to send it en bloc at the very end, so if an error occurs at some late stage of processing, there won't be any partial output (already sent to the browser) messing up an otherwise nicely formatted error page...