Make WordPress Core

Opened 6 years ago

Last modified 16 months ago

#18043 new defect (bug)

Uploaded images disappear after loading if using compression w/Apache

Reported by: ctsttom Owned by:
Milestone: Future Release Priority: normal
Severity: major Version: 3.2.1
Component: Upload Keywords: dev-feedback needs-testing needs-refresh
Focuses: multisite Cc:


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:


Please fix this asap!

Attachments (4)

Screen shot 2011-07-08 at 23.50.56.PNG (28.8 KB) - added by ctsttom 6 years ago.
Screen shot 2011-07-08 at 23.51.07.PNG (116.7 KB) - added by ctsttom 6 years ago.
18043.patch (559 bytes) - added by SergeyBiryukov 5 years ago.
patch.diff (478 bytes) - added by v-media 3 years ago.
Better patch for the bug #18043

Download all attachments as: .zip

Change History (29)

#2 @ctsttom
6 years ago

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'

#3 @ctsttom
6 years ago

Apache Modules under suspsicion is GZIP/ DEFLATE

#4 @ctsttom
6 years ago

  • Keywords needs-patch added
  • Version set to 3.2.1

#5 follow-up: @SergeyBiryukov
6 years ago

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

Last edited 6 years ago by SergeyBiryukov (previous) (diff)

#6 in reply to: ↑ 5 @ctsttom
6 years ago

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?

#7 @ctsttom
6 years ago

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

#8 @SergeyBiryukov
6 years ago

Thanks for the proper link.

Related: mu:#473

#9 @SergeyBiryukov
6 years ago

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.

#10 @ctsttom
5 years ago

This issue is still unresolved.

#11 @SergeyBiryukov
5 years ago

  • Keywords has-patch dev-feedback added; needs-patch removed

#12 @SergeyBiryukov
5 years ago

  • Keywords needs-testing added

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

#13 @OlivierMonaco
4 years ago

  • Cc OlivierMonaco added

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.

#14 @SergeyBiryukov
4 years ago

#23123 was marked as a duplicate.

#15 @v-media
4 years ago

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

#16 @SergeyBiryukov
4 years ago

  • Milestone changed from Awaiting Review to 3.6

#17 @v-media
4 years ago

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.

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.

Version 0, edited 4 years ago by v-media (next)

#18 @jtsternberg
4 years ago

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

#19 @azaozz
4 years ago

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

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

Last edited 4 years ago by azaozz (previous) (diff)

#20 @nacin
4 years ago

  • Milestone changed from 3.6 to Future Release

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

3 years ago

Better patch for the bug #18043

#21 @v-media
3 years ago

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.

#22 @SergeyBiryukov
3 years ago

  • Summary changed from Uploaded images dissapear after loading if using compression w/Apache to Uploaded images disappear after loading if using compression w/Apache

#23 @v-media
3 years ago

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.

#24 @jeremyfelt
3 years ago

  • Component changed from Multisite to Upload
  • Focuses multisite added

#25 @chriscct7
16 months ago

  • Keywords needs-refresh added; has-patch removed
Note: See TracTickets for help on using tickets.