Bug 75878 - Apache caches requests by default, or there is some bug around.
Summary: Apache caches requests by default, or there is some bug around.
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: php   
(Show other bugs)
Version: 8.0
Hardware: athlon Linux
Target Milestone: ---
Assignee: Joe Orton
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-10-14 13:48 UTC by vigna
Modified: 2007-04-18 16:47 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-11-29 13:51:06 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2003:017 high SHIPPED_LIVE : Updated PHP packages available 2003-01-21 05:00:00 UTC

Description vigna 2002-10-14 13:48:36 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020809

Description of problem:
Apache caches internally uncacheable content in a stock configuration.

I am developing this tool, ERW (http://erw.dsi.unimi.it) that we use to do
content management. The tool uses remote scripting to interact with a database.
This means that there is a hidden IFRAME element whose content is pointed at a
suitable URL; as a result, some JavaScript code is generated in the IFRAME
element and this code modifies via the DOM the appearance of the main web page.

For this to work, the URLs that are used to set the IFRAME element content
*must* be uncacheable (as what they return is dependent on the database
content). To this purpose, I do my best, doing stuff such as 

Header("Expires: Mon, 01 Jan 2001 00:00:01 GMT");             // Date in the past
Header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");// always modified
Header("Cache-Control: no-cache, must-revalidate");           // HTTP/1.1
Header("Pragma: no-cache");                                   // HTTP/1.0

This worked perfectly in the last three years. With Apache 2.0, request are sent
to the server (as I can see them in the access_log file), but the content is
cached by Apache (as I do heavy logging in my PHP code, and nothing appears).
The consequences are pernicious at best. In practice, the whole application
becomes unusable.

If I kill the Last-Modified header, however, everything works. Apparently Apache
is inferring that it can cache content on the basis of some offset from
Last-Modified, *even if the page has expired!*

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Try the following PHP script:


Header("Expires: Mon, 01 Jan 2001 00:00:01 GMT");             // Date in the past
Header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");// always modified
Header("Cache-Control: no-cache, must-revalidate");           // HTTP/1.1
Header("Pragma: no-cache");                                   // HTTP/1.0
Header("Content-Script-Type: text/javascript");                           //
JavaScript as default scripting language

error_log("Test", 0);


If you access it, and hit reload, you will see the access_log entry but nothing
in your PHP log. If you delete the Last-Modified line, clear the browser cache,
access and reload, you will see the access_log entry and "Test" in your PHP log.
There was no difference previously.

Additional info:

Comment 1 Mike Bonnet 2002-10-14 19:27:41 UTC
I have also encountered this problem.  Apparently apache checks the timestamp on
the PHP file, and if it has not been modified after the date in the
"If-Modified-Since" header sent by the browser, it doesn't run the PHP at all. 
An extensive discussion of this bug is available here:


It appears this bug would probably affect everyone trying to use PHP with apache

Comment 2 Need Real Name 2002-10-15 15:47:38 UTC
More discussion of this bug is available here:


If you replace 'header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");'
with 'header("Last-Modified: Mon, 26 Jul 1997 05:00:00 GMT");', apache will no
longer send a "304 Not Modified" when the PHP script is accessed a second time.

Comment 3 Mike Bonnet 2002-10-15 16:00:48 UTC
The "Last-Modified" workaround mentioned above works for Mozilla, but not IE. 
IE sends a "If-Modifed-Since" header with the date when the page was *cached* on
the browser, ignoring the "Last-Modified" header sent by the server.  The only
fix here is to never send 304's when serving PHP pages (which seems like the
right thing to do anyway).

Comment 4 Need Real Name 2002-11-07 13:33:55 UTC
Per the apache site this problem is fixed in 2.0.42 and later. See:


Will there be an updated httpd rpm released?

Comment 5 Joe Orton 2002-11-28 15:48:20 UTC
This is a PHP bug not an Apache bug; Apache versions >2.0.40 won't make any
difference to this problem. (2.0.40 has the changes which allow modules to
fix this problem, but it requires the module's cooperation)

Comment 6 Need Real Name 2002-11-28 16:34:30 UTC
I hate to push the issue, but this is directly from the apache bug site:


Please take the time to read this.  Everyone at apache said that this was a PHP
issue also, however they have seen the error in their thinking.  If you are
short on time you can read last comments entered:

------- Additional Comments From Justin Erenkrantz 2002-09-29 16:30 -------

This should be fixed in Apache 2.0.42 and later.

Unknown when exact fix was committed (probably much earlier than 2.0.42), but
the behavior works as expected for filtered content now.

Justin's email is: jerenkrantz@apache.org

I am not trying to be a pain, but please read the previous discussions about

I have confirmed that 2.0.43 has a fix for this myself on a Debian system.  I
compiled the apache code myself.

Comment 7 Joe Orton 2002-11-28 17:02:12 UTC
Really, are you sure? Using what version of PHP? AFAICT it is marked fixed at
apache.org since the Apache side of the bug was indeed fixed.

I have a working tested fix for PHP (using Apache 2.0.40), in any case.

Comment 8 Need Real Name 2002-11-29 01:43:35 UTC
I have php 4.2.2-8.0.5.  Is there a newer rpm released yet?

And yes apache has it marked as fixed.  They have version 2.0.43 stable, the fix
was in by 2.0.42.

Comment 9 Joe Orton 2002-11-29 09:56:59 UTC
No, I meant which version of PHP were you using on your Debian system where you
have verified that upgrading to 2.0.42 fixes this?  There isn't a newer PHP RPM
available yet, sorry - there will be soon hopefully.

Note the "probably much earlier than 2.0.42" w.r.t. the bug being marked fixed
at apache.org; the change in question was actually included in 2.0.40; see 

  *) Add a filter_init parameter to the filter registration functions
     so that a filter can execute arbitrary code before the handlers
     are invoked.  This resolves a problem where mod_include requests
     would incorrectly return a 304.  [Justin Erenkrantz]

Comment 10 Need Real Name 2002-11-29 13:50:59 UTC
Offering a most humble apology, and hoiking down my humble pie.. 

I have 4.1-1 on the debian system, and all works...

My real concern is with my RedHat system.  My wife is using phpBB on her web
site.  When someone posts a message they have to use either ctrl-refresh or
shift-reload to view new messages.  This becomes a problem for them.  What fix
can I apply to my system?  I tried uninstalling apache 2, and reinstalling 1.3
and the site works again, however this is not what I would like.  

What can I do?  I re-read the last 2 messages at
Unfortunately I cannot decypher the "patch".  What can I do?

Comment 11 Joe Orton 2002-12-04 08:49:56 UTC
This is fixed in php-4.2.2-10 - thanks for the reports.

Comment 12 Need Real Name 2003-01-09 22:09:31 UTC
Where is the updated rpm?

Comment 13 Joe Orton 2003-01-09 22:23:48 UTC
Unsupported test RPMs are available from here:


Comment 14 Need Real Name 2003-01-10 01:19:00 UTC

Comment 15 Need Real Name 2003-01-10 03:08:29 UTC
I installed them, but they left the old versions on my system.  Now when I do a
rpm -q php I get:


I know that the packages are not supported yet, but any suggestions?

Comment 16 Need Real Name 2003-01-10 03:52:20 UTC
Thanks again for the links.  It seems to work with mozilla, but not MS IE.  I
would be happy to help debug this if you'd like.

Comment 17 Joe Orton 2003-01-10 10:58:31 UTC
I think use rpm -U not rpm -i to avoid installing two copies of the package; you
might need to "rpm -e --allmatches php php-imap ..." to get rid of them now.  An
easy way of downloading a bunch of RPMs which avoids web browers doing silly things:

$ mkdir /tmp/RPMS
$ cd /tmp/RPMS
$ wget -r -np -nd http://blah

Comment 18 Need Real Name 2003-01-10 12:29:30 UTC
I installed them with the -U, and did like you suggested to remove them.  Once
they were gone I reinstalled the new ones and the bug still seems to exist. 
Could there be anyway that the new rpm's didn't fully update my system?

Thanks for the wget info.  I try that next time I want to download stuff.

Comment 19 Mark J. Cox 2003-02-05 08:40:19 UTC
An errata 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.


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