Running Drupal on our webserver, passing the Content-Length header causes different, but always annoying issues on different browsers when downloading a file:

  • Firefox doesn't end its loading progress display.
  • Safari wants to download the file as octet-stream.
  • If it's an image, Konqueror doesn't display it.

I don't know what the exact cause for those problems is, as I verified that the transmitted content-length exactly matches the file's byte size.

Given that those problems don't appear when Content-Length is omitted, and other prominent modules like user and image don't pass the Content-Length header and it still works perfectly without it, I think it would be appropriate to get rid of this header. If it brings more problems than benefits, I vote for scrapping it. Patch is attached.

CommentFileSizeAuthor
filefield-scrap-content-length.patch702 bytesjpetso

Comments

jpetso’s picture

jpetso commented

It seems that the cause of this problem is the web server when it is configured to compress transferred files. Quote from mod_deflate.

If you evaluate the request body yourself, don't trust the Content-Length header! The Content-Length header reflects the length of the incoming data from the client and not the byte count of the decompressed data stream.

So specifying the byte count of the file breaks downloads when mod_deflate or other compression mechanisms are enabled.

fago’s picture

fago
Primary language German
Location Vienna
commented

I did some more investigation for this topic.

Regarding the quoted mod_deflate issue: I think this is just a note for developers evaluating the body theirself. If mod_deflate would produce crap with a Content-Length header set, this would make a lot of more trouble as both are quite common. Perhaps, someone with a running mod_deflate can verify that there are no problems.

I've tested sending content-length headers with php zlib output compression enabled - it's working.

Furthermore content-length header are needed for a progress bar, when people are downloading files. Then http://www.mnot.net/cache_docs/ suggests to do so:
Generate Content-Length response headers. It’s easy to do, and it will allow the response of your script to be used in a persistent connection. This allows clients to request multiple representations on one TCP/IP connection, instead of setting up a connection for every request. It makes your site seem much faster.

However this is more an issues for images than files I think. Anyway, I think Content-Length headers are valuable and we should keep them. If there are issues with them, we better fix them :)

dopry’s picture

dopry commented
Status: Needs review » Postponed (maintainer needs more info)

Is this content-length header still causing problems?

jpetso’s picture

jpetso commented
Status: Postponed (maintainer needs more info) » Closed (won't fix)

No, doesn't cause problems. I was keeping the issue open because I wanted to make sure Content-Length is (back) in all of filefield, imagefield and imagecache... which is the case now, so let's close and forget this issue.