Make WordPress Core

Opened 13 years ago

Last modified 5 years ago

#18043 new defect (bug)

Uploaded images disappear after loading if using compression w/Apache

Reported by: ctsttom's profile ctsttom Owned by:
Milestone: Future Release Priority: normal
Severity: major Version: 3.2.1
Component: Upload Keywords: dev-feedback needs-testing needs-refresh reporter-feedback
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:

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 13 years ago.
Screen shot 2011-07-08 at 23.51.07.PNG (116.7 KB) - added by ctsttom 13 years ago.
18043.patch (559 bytes) - added by SergeyBiryukov 13 years ago.
patch.diff (478 bytes) - added by v-media 11 years ago.
Better patch for the bug #18043

Download all attachments as: .zip

Change History (30)

#2 @ctsttom
13 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
13 years ago

Apache Modules under suspsicion is GZIP/ DEFLATE

#4 @ctsttom
13 years ago

  • Keywords needs-patch added
  • Version set to 3.2.1

#5 follow-up: @SergeyBiryukov
13 years ago

Related: #17181

Tried to find the reason behind that line. Seems is gone? Codex says the old MU tickets should still be available:

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

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

Replying to SergeyBiryukov:

Related: #17181

Tried to find the reason behind that line. Seems is gone? Codex says the old MU tickets should still be available:

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

#7 @ctsttom
13 years ago

SCRATCH THAT: there its an error in Codex I just corrected, issue still exists though.

#8 @SergeyBiryukov
13 years ago

Thanks for the proper link.

Related: mu:#473

#9 @SergeyBiryukov
13 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
13 years ago

This issue is still unresolved.

#11 @SergeyBiryukov
13 years ago

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

#12 @SergeyBiryukov
13 years ago

  • Keywords needs-testing added

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

#13 @OlivierMonaco
12 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
12 years ago

#23123 was marked as a duplicate.

#15 @v-media
12 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
12 years ago

  • Milestone changed from Awaiting Review to 3.6

#17 @v-media
12 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, 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.

Last edited 12 years ago by v-media (previous) (diff)

#18 @jtsternberg
11 years ago

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

#19 @azaozz
11 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 11 years ago by azaozz (previous) (diff)

#20 @nacin
11 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.

11 years ago

Better patch for the bug #18043

#21 @v-media
11 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
11 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
11 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
10 years ago

  • Component changed from Multisite to Upload
  • Focuses multisite added

#25 @chriscct7
9 years ago

  • Keywords needs-refresh added; has-patch removed

#26 @desrosj
5 years ago

  • Keywords reporter-feedback added

Is anyone still experiencing/able to reproduce this issue?

Note: See TracTickets for help on using tickets.