This is just an update on a topic that had been discussed a long time ago.
The issue was that files sent to a browser should have a content-length
header set with the length of the content. For FOP's dynamically generated
content this typically involves storing the FOP output to get the total size
(YUCK! - my personal opinion). The other option (under HTTP 1.1) is to use
chunked transfer encoding. I had been using this later technique
successfully with an old version of jRun for some time. To do this my
servlet was setting the Transfer-Encoding header to chunked and sending the
output in individual chunks with the appropriate length headers (actually it
only did chunked if the output was greater than the size of the buffer). Not
long ago we upgraded to Tomcat 4 and I noticed that some PDFs were not
displaying properly. Further analysis revealed that the chunk length headers
were getting included in the stream to the browser. Looking into this it
appears that Tomcat is smart enough to send the output chunked if you set
the Transfer-Encoding header to "chunked". In fact, I came across a blurb
somewhere that indicated that Tomcat would automatically chunk output that
was greater than it's buffer size (much as my servlet had done).

So, if my findings are correct and you are using Tomcat 4 then it may be
possible to stop storing the FOP output just to determine the
content-length. Of course this will probably require HTTP 1.1 compliant
browsers (etc).

This behavior seems fairly reasonable, so maybe all/most/other servlet
engines support this. It is a bit hidden though, I would prefer something
like HTTPServletResponse.setTransferEncoding(String) (akin to

So now the meat of my servlet's code to do chunking looks like:

        response.setHeader("HTTP-Version", "HTTP/1.1");
        response.setHeader("Transfer-Encoding", "chunked");
        out = response.getOutputStream();

What could be simpler.


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to