httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Johnson <...@indietorrent.org>
Subject [users@httpd] gzipping via mod_deflate, the DeflateBufferSize, the Content-Length header, and download progress in Web browsers
Date Wed, 12 Sep 2012 17:16:12 GMT
I have a "download page" that serves various types of content (PDFs, ZIP
files, images, etc.) via a PHP script that is executed atop Apache.

Whenever I enable GZIP compression on this page, via mod_deflate, Web
browsers do not show the total file size to be downloaded, presumably
because Apache is chunking the reply and the Content-Length header is
very small, e.g., 20 (even when the binary file size is several MB).

I came to this conclusion after finding these two related threads:

http://serverfault.com/questions/183843/content-length-not-sent-when-gzip-compression-enabled-in-apache

http://serverfault.com/questions/366996/how-can-the-apache-2-2-deflate-module-length-limit-be-increased

I'm able to reproduce the issue at will, and enabling mod_deflate
definitely causes the Content-Length header value to change to a low
value (and Web browser download progress to "break").

Perhaps this is "expected behavior". If that is the case, then I'm
wondering how to address the behavior; users can't live without a
progress bar for files this large (and I don't blame them).

Is it advisable to set the DeflateBufferSize directive to some
ridiculously large value? That just... "feels wrong". Some of the
file-downloads are 2GB in size, and I hesitate to set DeflateBufferSize
to 2097152000.

Would it be better to disable GZIP compression for all URLs within the
/download/ (for example) directory?

Or perhaps for certain file-types? Because I tried that with the
following, but it seems not to have any effect (I believe this example
to be directly from the Apache documentation, with a few additional
extensions added):

<Location />
SetOutputFilter DEFLATE

# Don't compress images (or other files that are already compressed)
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png|zip|7z|rar|sit?x|mp3|flac|ogg|pdf)$ no-gzip dont-vary

# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
</Location>

The URLs in question take the following format:

https://localhost/public/download/My%20Installer.zip

Also, I am setting the Content-Type header appropriately, e.g., to
"application/zip", given the above URL.

So, I'm not sure why that rule don't seem to be effective.

I would be happy to hear anybody's thoughts or suggestions.

Thank you for taking the time,

-Ben

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message