Bug 168850 - mod_expires doesn't correctly add Expires headers for HTTP 304 pages
mod_expires doesn't correctly add Expires headers for HTTP 304 pages
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: httpd (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
http://svn.apache.org/viewcvs.cgi?rev...
:
: 167851 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-20 13:35 EDT by Tarun Reddy
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2007-0445
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-11 14:42:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch for use in httpd src rpm. Applies against httpd-2.0.46-46.3.ent (2.24 KB, patch)
2005-09-20 16:17 EDT, Tarun Reddy
no flags Details | Diff

  None (edit)
Description Tarun Reddy 2005-09-20 13:35:36 EDT
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
Comment 1 Tarun Reddy 2005-09-20 13:37:26 EDT
Actually the URL is in the Additional Bug Information
Comment 2 Tarun Reddy 2005-09-20 16:17:14 EDT
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.
Comment 3 Joe Orton 2005-09-21 07:56:36 EDT
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.
Comment 4 Steve Wilson 2005-10-21 15:22:45 EDT
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?
Comment 5 Tarun Reddy 2005-10-21 15:42:40 EDT
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.
Comment 6 Steve Wilson 2005-10-24 11:58:52 EDT
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/
Comment 7 Joe Orton 2005-11-02 13:31:18 EST
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.
Comment 8 Steve Wilson 2005-11-03 12:45:34 EST
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.
Comment 9 Tarun Reddy 2005-11-03 13:12:24 EST
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
Comment 10 Tarun Reddy 2006-01-05 11:22:21 EST
Was Joe Orton's patch applied to the latest security release , i.e. httpd-2.0.46-56?

Comment 11 Steve Wilson 2006-01-05 14:35:58 EST
From the change log and some cursory testing, it doesn't appear httpd-2.0.46-56
includes the 304 expiration patch.
Comment 12 Tarun Reddy 2006-01-05 15:43:34 EST
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.
Comment 13 Tarun Reddy 2006-07-20 15:02:14 EDT
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
Comment 14 Steve Wilson 2006-08-04 14:16:10 EDT
I've successfully tested Tarun's packages from http://www.rallydev.com/downloads/

Thanks for creating them once again.
Comment 19 Joe Orton 2007-03-15 11:33:32 EDT
*** Bug 167851 has been marked as a duplicate of this bug. ***
Comment 23 Red Hat Bugzilla 2007-06-11 14:42:13 EDT
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

Note You need to log in before you can comment on or make changes to this bug.