Bug 168850
| Summary: | mod_expires doesn't correctly add Expires headers for HTTP 304 pages | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Tarun Reddy <tvr1> | ||||
| Component: | httpd | Assignee: | Joe Orton <jorton> | ||||
| Status: | CLOSED ERRATA | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 3.0 | CC: | swilson, tao | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| URL: | http://svn.apache.org/viewcvs.cgi?rev=102210&view=rev | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | RHBA-2007-0445 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2007-06-11 18:42:12 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Actually the URL is in the Additional Bug Information Created attachment 119046 [details]
patch for use in httpd src rpm. Applies against httpd-2.0.46-46.3.ent
I added this patch as the last patch of my httpd src rpm and rebuilt. It fixes
the issue.
Thanks for the report. We're aware of the problem and the resolution, but adding this patch as-is would mean that old versions of the httpd binary could not load the new mod_expires DSO, which can cause existing installations to crash when the upgrade is installed. (i.e if the upgrade is installed then the old httpd binary is SIGHUPed to reload DSOs) Note also that this bug does not affect RHEL4. We have also run into this issue. The missing Expires header on 304 responses does not appear to be corrected in the latest httpd-2.0.46-54.ent package. Any idea when a fix will be generally available? According to comment #3, it won't ever be fixed. I've resorted to creating my own patched RPM. You can download the RPMS (both src and i386) at my site: http://www.rallydev.com/downloads/ This is NOT Redhat supported, but you can see the patch in the src.rpm. It is the file httpd-2.0.46-expires304.patch. Very similar to the patch I attached in comment #2. Please restart, not reload, after installing this RPM. Thanks for the patch in comment #2. I was able to aply it successfully against both httpd-2.0.46-46.3.ent.src.rpm and httpd-2.0.46-54.ent.src.rpm. I had no problems installing the result with an httpd restart. I'm surprised more folks haven't complained about this issue. It's reportedly killing some of the more latency sensitive vxml applications we run. I guess there's always httpd source and rpm's from Apache, but I just hate to drift from the RHEL3 packages unless absolutely necessary. I'll also test your httpd-2.0.46-54.1.ent packages from http://www.rallydev.com/downloads/ Experimental test packages are now available which contain a patch to correct this issue. These packages are unsupported and have not gone through the Red Hat QA process. http://people.redhat.com/jorton/Taroon-httpd/ Any feedback from testing these packages is very welcome. I've successfully tested the packages from http://people.redhat.com/jorton/Taroon-httpd/ against our apps. The Expires header appears on 304 responses and all seems well. I was also successful in using those RPMS. I just wished they were versioned 54.2 since they now conflict with the RPMS I had created and don't upgrade cleanly.... oh well. I removed the old httpd and mod_ssl and reinstalled, fixing all moved httpd.conf and ssl.conf Was Joe Orton's patch applied to the latest security release , i.e. httpd-2.0.46-56? From the change log and some cursory testing, it doesn't appear httpd-2.0.46-56 includes the 304 expiration patch. I've updated httpd-2.0.46-56 rpms with Joe's 304 expiration patch. They are available at http://www.rallydev.com/downloads/ . And now the link to them actually works. They are listed as httpd-2.0.46-56.1.ent.i386.rpm, etc. and the SRPM is available for your viewing. I guess this patch is never going to make it to RH3's httpd. Once again, taken Joe's patch and applied it to 2.0.46-57. http://www.rallydev.com/downloads/ . Please make sure to download correct RPMS I've successfully tested Tarun's packages from http://www.rallydev.com/downloads/ Thanks for creating them once again. Updated again. Applied to 2.0.46-61. http://www.rallydev.com/downloads/ For me, rpm -Uvh http://www.rallydev.com/downloads/httpd-2.0.46-61.1.ent.i386.rpm http://www.rallydev.com/downloads/mod_ssl-2.0.46-61.1.ent.i386.rpm *** Bug 167851 has been marked as a duplicate of this bug. *** An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0445.html |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4 Description of problem: When using mod_expires options, browsers upon first connection will get the file plus an Expires and Cache-control Header. This is correct. However upon subsequent tests after the Expires date has passed, if the file hasn't change, Apache reports back correctly a 304, but does not include a new Expires header. As a result the browser, storing the old Expires date, will always from that point on, test to see if the file has changed, generating excessive 304 checks. While generally not deterimental on high bandwidth connections, this is severaly hurtful to lowbandwidth, high latency connections. Version-Release number of selected component (if applicable): httpd-2.0.46-46.3.ent How reproducible: Always Steps to Reproduce: 1. Set appropriate mod_expire tags. I am using this in conf/httpd.conf ExpiresActive On ExpiresDefault A300 <FilesMatch "\.(gif|jpg|png|ico|js|css)$"> ExpiresDefault A86400 </FilesMatch> 2) Test Expires Header with no 'If-Modified-Since' header curl -s -I http://www.rallydev.com/images/rally_logo.gif correct headers are returned. 3) Test Expires Header with 'If-Modified-Since' header curl -s -I http://www.rallydev.com/images/rally_logo.gif -H 'If-Modified-Since: Mon, 19 Sep 2005 23:13:56 GMT' Actual Results: The 304 header returns: HTTP/1.1 304 Not Modified Date: Tue, 20 Sep 2005 17:32:50 GMT Server: Apache/2.0.46 (Red Hat) Connection: close ETag: "2200c6-88c-eb040d00" Expected Results: On an RHEL 4 system, correct headers are returned see curl -s -I http://stjohn.rallydev.com/images/rally_logo.gif -H 'If-Modified-Since: Mon, 19 Sep 2005 23:13:56 GMT' returns HTTP/1.1 304 Not Modified Date: Tue, 20 Sep 2005 17:34:45 GMT Server: Apache-Coyote/1.1 Connection: close Expires: Tue, 20 Sep 2005 17:39:45 GMT Cache-Control: max-age=300 Additional info: The URL above shows the svn commit for this particular bug. I am attempting to come up with a patch against the latest httpd RPM