tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Toth <>
Subject Re: Byte-serving PDFs unsupported? Or broken?
Date Mon, 15 Sep 2008 01:26:56 GMT
Hi one more time,

I was in fact able to solve this with a simple filter, though this is not
a general solution. In hopes that this helps someone else, the filter
is included below.


Fred Toth

package com.toth.filter;

import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.ServletException;
import javax.servlet.FilterConfig;

public class AcceptRangesFilter implements Filter {

        public void init(FilterConfig config) throws ServletException {


         * This handles a long-standing tomcat bug (sort of). Tomcat 
supports the
         * underlying mechanism of byte serving of PDFs. However, the 
only way
         * to kick this mechanism into action is by telling the Acrobat 
         * that we accept byte range requests. The HTTP spec does not 
require this,
         * but Adobe does. This should really be fixed in DefaultServlet 
but this
         * gets the job done for now.
         * See:
        public void doFilter(ServletRequest request, ServletResponse 
                        FilterChain chain) throws IOException, 
ServletException {

                HttpServletRequest req = (HttpServletRequest) request;
                HttpServletResponse res = (HttpServletResponse) response;
                String uri = req.getRequestURI().toLowerCase();

                if (uri != null && uri.endsWith("pdf")) {
                        res.setHeader("Accept-Ranges", "bytes");

                chain.doFilter(request, response);


        public void destroy() {

Fred Toth wrote:
> Hello again,
> After a bit more looking, I found this discussion in bugzilla from 
> this July:
> In short, according to the discussion, correct interaction with the
> Adobe plugin requires that a server send the "Accept-Ranges" header
> in response to the initial request. The Adobe plugin sees this and then
> proceeds to read the PDF file in chunks instead of requesting the
> whole thing.
> Currently, the tomcat DefaultServlet does not set this header, even 
> though
> it supports the Content-Range requests.
> It appears that I can work around this with a filter. I'll report back 
> on that
> after I've got one going.
> Can anyone comment on the status of this bug?
> Many thanks,
> Fred Toth
> Fred Toth wrote:
>> Hi all,
>> I've been trying to get to the bottom of an old question:
>> Does tomcat support byte-serving of PDF files? In searching the 
>> archives,
>> this comes up every few years or so and most responses are confusing
>> and inconclusive.
>> Here's more detail on the question, starting with my symptoms:
>> For unrelated reasons, I just switched a client's site from using 
>> apache to using tomcat 5.
>> I immediately starting hearing "PDFs are slower to download". I was 
>> able to confirm
>> this. For example, a 14mb PDF on my connection using tomcat takes 
>> about 45 seconds before
>> the first page appears in the browser. On a generic apache install, I 
>> see the first page
>> in approximately 1 second.
>> The reason for this is that tomcat, out of the box, does not appear 
>> to support "byte serving",
>> or, possibly, it doesn't support it in a form that's acceptable to 
>> Adobe Acrobat
>> browser plug-ins.
>> To understand this one needs a bit of info on PDF internals:
>> It is possible to create PDFs that are "optimized for web view". PDFs 
>> in this form are
>> rearranged internally such that the first page can be delivered more 
>> quickly. (Earlier PDFs
>> kept all pointer information at the end of the file, which meant the 
>> entire file had to
>> be downloaded before the reader could find the first page.)
>> The apache web server supports these "optimized" PDFs with no 
>> particular configuration.
>> However, tomcat does not.
>> What I can't seem to find out is if this is just not supported? Or 
>> does it require some
>> specific tomcat configuration? Or does the Acrobat plug-in bend the 
>> specification
>> in a way that apache handles, but tomcat does not?
>> The underlying technology is based on particular HTTP headers. 
>> "Accept-Ranges" is used
>> by the server to say, "Yes, you can ask me for byte ranges of a 
>> file". The browser (or, in
>> this case, the Acrobat plug-in) responds with specific Content-Range 
>> requests, essentially treating
>> the PDF file as a random-access file.
>> I'm amazed that this doesn't come up more often, considering the 
>> prevalence of PDFs
>> (and the prevalence of tomcat!)
>> Also, here are some common discussion comments that are NOT the 
>> answer I'm seeking:
>> 1. Yes, tomcat serves PDFs out of the box quite nicely.
>> 2. Yes, one can use apache to serve PDFs instead of tomcat. This is 
>> not an option
>> in my case because I'm using tomcat to implement access control to 
>> those PDFs.
>> 3. Yes, I know that one could write code to solve this, but I'm 
>> hoping that DefaultServlet
>> can do this. It's not trivial to implement.
>> 4. I've seen comments that indicate that there is general support in 
>> tomcat for Accept-Ranges
>> and Content-Range. But I've also seen indications that Acrobat might 
>> require some specific
>> flow of headers before it does the right thing. I can confirm that 
>> neither tomcat 5 nor tomcat 6
>> handle this properly (at least with a generic configuration).
>> 5. Yes, 14mb is quite large for a PDF and there are ways to make 
>> smaller PDFs. This particular
>> client has specific reasons for using such large PDFs.
>> 6. This has nothing to do with generating PDFs on the fly. These are 
>> PDF files sitting
>> quietly in the web root.
>> Thanks for any advice you might have!
>> Fred Toth
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail:
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To start a new topic, e-mail:
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message