Uploaded images disappear after loading if using compression w/Apache

[ctsttom]

I have found an issue between WordPress (Multisite) + Google Chrome (Mac) which I think appeared on my sever when I enabled compression a few months ago, but could never reproduce because it only happens with images managed by a Multisite WordPress install, not static images.

With images that are static Apache sends the file and calculates the Content-Length its self so these images work fine but if you access a file uploaded to WordPress it uses the .htaccess redirect so the image requests are sent via ms-files.php for what ever reason.

The problem is that WordPress decides to calculate its own Content-Length header in the HTTP Response which means that security conscious browsers like Google Chrome freak out when the data they receive is less than they we're told by Apache and they resultantly disable the image.

The Content-Length calculation comes on line 43 of ms-files.php I don't know why its needed because Apache seems to sort it out automatically if you don't send your own header, in fact most of the file seems like an unnessisary load of processing, perhaps it needs reviewing but this is a major issue as it is a growing browser, on a growing platform.

Here is a great video of it in action: ​http://www.screencast.com/t/cUYKSegW0N

This issue has been repeatedly reported on the forum:

​http://wordpress.org/support/topic/disappearing-images
​http://wordpress.org/support/topic/multisite-images-broken
​http://wordpress.org/support/topic/image-not-show-in-google-chrome-timthumbphp

Please fix this asap!

[ctsttom]

Further reading:
​http://www.permies.com/permaculture-forums/8724_0/tinkering-with-this-site/attached-photos-dont-display-in-google-chrome

[ctsttom]

These images show the web inspector in Google Chrome Mac, the file shows status 200 from the apache server but chrome soon says (failed) when the connection closes from Apache and the data is 'incomplete'

[ctsttom]

Apache Modules under suspsicion is GZIP/ DEFLATE

[SergeyBiryukov]

Related: #17181

Tried to find the reason behind that string. Seems ​http://trac.mu.wordpress.org/ is gone? Codex says the old MU tickets should still be available: ​http://codex.wordpress.org/WPMU_Trac

[ctsttom]

Replying to SergeyBiryukov:

Related: #17181

Tried to find the reason behind that line. Seems ​http://trac.mu.wordpress.org/ is gone? Codex says the old MU tickets should still be available: ​http://codex.wordpress.org/WPMU_Trac

I had that problem too, not sure why mu trac has gone?

[ctsttom]

SCRATCH THAT: ​http://mu.trac.wordpress.org/ there its an error in Codex I just corrected, issue still exists though.

[SergeyBiryukov]

Thanks for the proper link.

Related: ​mu:#473

[SergeyBiryukov]

Looks like we have at least two cases where Content-Length is needed (​mu:#473, #17181) and other two when it's not needed (​mu:#1078, #18043), for both Apache and IIS.

The first two seem strange though. According to RFC 2616, Content-Length should not be sent together with Transfer-Encoding:

If a Content-Length header field (section 14.13) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header field MUST NOT be sent if these two lengths are different (i.e., if a Transfer-Encoding header field is present). If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.

I wonder if the issues in the first two tickets could be caused by a server misconfiguration.

[ctsttom]

This issue is still unresolved.

[SergeyBiryukov]

Needs testing under various Apache and IIS configurations, with and without compression, etc.

[OlivierMonaco]

I'm using WordPress 3.4.2 as a multi-site installation with Apache and PHP-FPM and have the same problem. If I configure Apache to do the compression and to use persistant connections (Keep-Alive), Chrome waits until the the Keep-Alive timeout expires. If I disable the compression or the use of persistant connections, all works fine. If I comment the line in ms-files.php which add the Content-Length header, all works fine.

Modifing Apache configuration is not really an option.

Modifing ms-files.php is not an option if download of big files becomes impossible. So I put a MP3 file of 12 MiB and had no problem to fully download/listen it from Chrome and Firefox under Windows 7.

So, for me, it's better to remove this code.

[SergeyBiryukov]

#23123 was marked as a duplicate.

[v-media]

My report was duplicate. But what are the solutions? I can provide more details, but I believe it's a bug in WP...

[v-media]

I checked your patch, and I would say, this will result in an unknown file-size. I don't think it's a good idea, especially if we speak about large files. The better solution could be some refactoring of ms-files.php and checking for 304 before you send Content-Length. This will allow sending Content-Length only for 200. I can't provide you a patch since this doesn't seem to be a quick change, but hope you agree that the idea is right.

The other problem with such a patch is that someone later can add these lines again, since users will eventually ask to send the Content-Length and there will be no obvious reason why not to do it.

[jtsternberg]

This has been an issue for me for a while now. Can we get some more attention to the issue?

[azaozz]

Media files (images, audio, video) shouldn't be compressed by the server. It not only increases server load, but in most cases produces files that are slightly larger in size. Best fix here seems to be to disable compression for content coming from ms-files.php. Example from Apache's ​mod_deflate config:

<Location />
# Don't compress images
SetEnvIfNoCase Request_URI \
(?:\.gif|\.jpe?g|\.png|ms-files\.php)$ no-gzip dont-vary

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

(Note: this is the module configuration not .htaccess)

[nacin]

v-media introduces some uncertainty here, otherwise 18043.patch​ seemed good for commit. Punting for further discussion.

[v-media]

Better patch for the bug #18043

[v-media]

I think, there is a better solution than the patch in this task. Please see the bug #24312. It actually duplicates #18043. But the solution proposed by the reporter is better. header() by default replaces the same header type and in this case it will just override the initial Content-Length. Although, it's not a perfect solution, it works without issues. Please see the attached diff for reference.

[v-media]

The title for this issue is still not perfect: the problem is not only about Apache. I use nginx everywhere, but have the same issue.

[desrosj]

Is anyone still experiencing/able to reproduce this issue?