When looking in our Apache access log, when users are downloading PDF files from our server, the following often (but not always) happens. The URL is first requested and delivered with a status 200 (ok) and the full reply size, then immediately following are numerous requests for the same URL from the same client, with a smaller reply size and a 206 (partial reply) status code.

In other words, some clients first download the entire PDF successfully, then appear to download numerous "chunks" of the file again.

Why are we seeing this?


These are "byte range" requests (an HTTP/1.1 feature), which are typically made by the Adobe Reader browser plugin.

They are intended to support being able to follow a link in your browser to a theoretical 50 MB PDF, get the table of contents, follow a link in the TOC to the last page or two, and the reader downloads the last few pages, giving you immediate access to what you seek, and continuing to download the rest of the PDF in the background.

Some Adobe Reader versions called this "fast web view".

I'm not certain why you would be seeing a full request first with the full file size, so I'm not sure if I've answered your question satisfactorily.

Following a hunch, I found some further reading that seems to confirm that the browser's original HTTP request for the file will often continue in the background after handing off to the Adobe plugin. The plugin makes various byterange requests, but the browser's original request ends up being for the full size of the file, since it wasn't a byterange request to begin with.

I'm not sure if Adobe would see this as a bug or not. It could effectively double the data transferred, but it could make the "user experience" on the client side of things "seem faster / more responsive". :)

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy