Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Safari/Firefox/Chrome only show an indeterminate progress bar when downloading large files, although the content-length header is set. Any idea why that could be? This is a standard(-ish) Apache 2.2 install.

bash# curl -I
HTTP/1.1 200 OK
Date: Mon, 14 Dec 2009 13:35:04 GMT
Server: Apache/2.2.3 (Debian) DAV/2 SVN/1.4.2 mod_python/3.2.10 Python/2.4.4 PHP/5.2.0-8+etch15 mod_ssl/2.2.3 OpenSSL/0.9.8c mod_wsgi/2.3 mod_perl/2.0.2 Perl/v5.8.8
Last-Modified: Mon, 14 Dec 2009 11:54:22 GMT
ETag: "11acd74-1e7c1de-ef263780"
Accept-Ranges: bytes
Content-Length: 31965662
Vary: Accept-Encoding
Content-Type: application/x-msdos-program
share|improve this question
Here is the answer I sure that,,,It will help you...… – Manohar Kumar May 15 '15 at 3:21
up vote 1 down vote accepted

What do you mean by "intermediate progress bar"? - does it not show at all in the downloads box or just not show progress. What sort of size of file does it show for and not? What speed is your connection to that server from the machine you are testing from?

It could be that you are simply not seeing any progress for smaller files because they come down so quickly there is never time to display it. This can be the case even if the download isn't instantaneous as the process is more than just "get the contents" - it is:

  1. request the object (this usually takes a very short amount of time, slightly longer for HTTPs, but could take longer if the server or your link are busy)
  2. wait for the first info to come down (this can take a short while if it is the result of a script and/or you are using mod_gzip or similar as in those cases the process on the web server may wait until the entire script is complete before sending even the first byte of data)
  3. transfer the data - for small files this may be visually instantaneous on a fast link (the progress bar may not be drawn until the first byte arrives, and the last byte might arrive a fraction of a second after that) so the progress bar is there and gone faster than you can see
  4. post-download jigger-pokery (AV checks and so forth) which can take a while depending on your setup

Only in step 3 would you expect a progress bar, and it may only be a fraction of the download time on a fast link. Some proxy arrangements may exacerbate this, as they may buffer a larger file that takes several seconds (or tens of seconds, or more) to transfer on your external network connection such that the client application sees the request go out, waits for the first byte of response (during which time the proxy is actually getting the file) and gets it all in a fraction of a second in one go from the proxy (so step 3 above is near instant from its point of view).

All the above is quite generic - you'll need to add some more details and analysis to your question for a more specific answer.

share|improve this answer
The problem seems to be the "SetOutputFilter DEFLATE" that I added to .htaccess. By removing the line, I do get a progress bar that can show the length. Thank you for your reply! – Frederik Dec 15 '09 at 11:38

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.