in reply to CGI Question

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...

Replies are listed 'Best First'.
Re^2: CGI Question
by ww (Archbishop) on Apr 02, 2009 at 21:57 UTC

    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="...."'.

[reply]
[d/l]
[select]

      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.

[reply]
[d/l]

        Consider this crude (uses some deprecated elements; fails accessibility standards; other shortcomings) example:

        <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http:/
+/www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>demo</title>
<meta http-equiv="Content-Style-Type" content="text/css">
</head>
<body>

<table summary="your order">
<thead>
<tr><th>Item</th>
<th>Item #</th>
<th>Shiping</th>
<th>Unit Price</th>
<th>Quantity</th>
<th style="text-align:right;">Item Total</th>
</tr>
</thead>
<tbody>
<tr>
<td>foo</td>
<td>12345</td>
<td>Post</td>
<td>9.99</td>
<td>10</td>
<td style="text-align:right;">99.90</td>
</tr>
<tr>
<td>bar</td>
<td>123456</td>
<td>Bicycle Messenger</td>
<td>1.99</td><td>1000</td>
<td style="text-align:right;">1999.00</td></tr>
<tr><td>blivitz</td>
<td>1234567</td>
<td>Pony Express</td>
<td>9.99</td><td>10</td>
<td style="text-align:right;">9999.00</td>
</tr>
<tr><td colspan="6"> ...Many more rows with item totals of &lt; 10,000
+.00 .... </td></tr>
<tr>
<td colspan="5" style="text-align: right;">Order Total:</td><td style=
+"text-align:right;">125,567,097.90</td></tr>
</tbody>
</table>

        [download]

        Before the rendering engine can calculate a proper width for the last column, it must know the maximum width needed (ie, 14 characters for the last col of the last row), which it cannot know until all <table> (or, at least, all <tbody> in this case) has been received.

        Were it to start after receipt of the first <tbody> row, the width it allocated would be inadequate for the last cell in the row containing "Order Total:" and it would therefore have to re-render the rows above. It could, of course, be engineered to do it that way, but the consequence would be additional load on the processor and screen jitter for the viewer... which is why browsers (well, those with which I have any familiarity) do not render tables until they have width info, whether from complete receipt of the table or width info from the tags, as, for an even cruder example:

        <table width="90%" summary="Using widths (should use css these days)">
<tr>
<td width="10%">something</td>
<td width="50%">something longer</td>
<td width="40%">middlin' long</td>
</tr>
</table>

</body>
</html>

        [download]

        The second example allows the rendering engine to assign/allocate appropriate widths without waiting for all data.

[reply]
[d/l]
[select]
Re^2: CGI Question
by njweatherman (Sexton) on Apr 02, 2009 at 18:42 UTC
    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!
[reply]
      ...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...

[reply]
        Your right! I read through the documentation to fast. I just came across another article and it said to set the STDOUT to $|=1
[reply]

In Section Seekers of Perl Wisdom