WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 3 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: has-patch dev-feedback needs-testing
Focuses: multisite Cc:

Description

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!

Attachments (4)

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

Download all attachments as: .zip

Change History (28)

comment:2 ctsttom3 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'

comment:3 ctsttom3 years ago

Apache Modules under suspsicion is GZIP/ DEFLATE

comment:4 ctsttom3 years ago

  • Keywords needs-patch added
  • Version set to 3.2.1

comment:5 follow-up: SergeyBiryukov3 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 3 years ago by SergeyBiryukov (previous) (diff)

comment:6 in reply to: ↑ 5 ctsttom3 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?

comment:7 ctsttom3 years ago

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

comment:8 SergeyBiryukov3 years ago

Thanks for the proper link.

Related: mu:#473

comment:9 SergeyBiryukov3 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.

comment:10 ctsttom3 years ago

This issue is still unresolved.

SergeyBiryukov3 years ago

comment:11 SergeyBiryukov3 years ago

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

comment:12 SergeyBiryukov3 years ago

  • Keywords needs-testing added

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

comment:13 OlivierMonaco19 months 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.

comment:14 SergeyBiryukov16 months ago

#23123 was marked as a duplicate.

comment:15 v-media16 months ago

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

comment:16 SergeyBiryukov16 months ago

  • Milestone changed from Awaiting Review to 3.6

comment:17 v-media16 months 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 16 months ago by v-media (next)

comment:18 jtsternberg11 months ago

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

comment:19 azaozz10 months 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
</Location>

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

Last edited 10 months ago by azaozz (previous) (diff)

comment:20 nacin9 months 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.

v-media6 months ago

Better patch for the bug #18043

comment:21 v-media6 months 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.

comment:22 SergeyBiryukov5 months 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

comment:23 v-media5 months 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.

comment:24 jeremyfelt3 months ago

  • Component changed from Multisite to Upload
  • Focuses multisite added
Note: See TracTickets for help on using tickets.