From: n dot sherlock at gmail dot com
Operating system: Vista 64 bit, Ubuntu
PHP version: 5.3.0
PHP Bug Type: Apache2 related
Bug description: PHP incorrectly sets no_local_copy=1 on response as Apache 2
module
Description:
------------
If PHP (5.3.0) is running as an (Apache 2) module, it currently sets
no_local_copy to 1 on the response it sends to Apache
(sapi/apache2handler/sapi_apache2.c:463). It looks like this flag was set
to disallow Apache from erroneously creating its own "304 Not Modified"
responses based on the ETag or Last-Modified-Date of the PHP scripts'
sourcecode itself, which would result in stale pages being served if the
scripts' output changes over time.
But there's a serious side effect of setting this flag in combination with
Apache's mod_cache. If the browser makes a conditional request for a cached
PHP document, but the document is expired in the cache, mod_cache correctly
passes on the conditional request to PHP. If the PHP script responds with a
"304 Not Modified" code, mod_cache should generate a 304 response for the
browser. But due to no_local_copy, Apache is denied from creating a 304
code in response to a request for a PHP document. This forces it to resend
the (still valid) body of the PHP document from the cache with a 200 code.
But setting "no_local_copy=1" is not needed anyway. Just below the
r->no_local_copy=1 line in sapi_apache2.c is a series of calls to
apr_table_unset which remove any headers that Apache might have generated
based on the PHP source itself and could be using to accept conditional
requests. Starting at line 468 in php_apache_request_ctor, we have:
apr_table_unset(r->headers_out, "Content-Length");
apr_table_unset(r->headers_out, "Last-Modified");
apr_table_unset(r->headers_out, "Expires");
apr_table_unset(r->headers_out, "ETag");
It seems to me that removing the r->no_local_copy=1 will therefore not
result in erroneous "304 Not Modified" responses being sent by Apache for
PHP scripts.
At the moment if you request a mod_cache'd PHP page which itself sends no
special caching directives (e.g. an empty script), the reply from the
server is (trimmed to include only cache-relevant directives):
Status=OK - 200
Date=Sun, 26 Jul 2009 10:07:58 GMT
PHP has correctly suppressed the generation of Last-Modified-Date and ETag
headers based on the source of the script itself. No conditional request is
possible and you won't get a stale page.
Now, if you request a PHP document that does set "ETag", such as the
attached code "index.php", the response from the server is:
Status=OK - 200
Date=Sun, 26 Jul 2009 10:11:02 GMT
Etag="ComputedETag"
Expires=Tue, 25 Aug 2009 10:11:02 GMT
And the error log shows that the script correctly returned a 200 response
code to Apache. Now if you press "refresh" in Firefox, the browser sends
this request:
If-None-Match="ComputedETag"
Cache-Control=max-age=0
This is a conditional get which will also result in Apache revalidating
its cache (since max-age=0). So Apache passes the conditional request onto
PHP, and PHP sends back a 304 Not Modified response. But due to
no_local_copy, mod_cache cannot send a 304, it responds to the browser
with:
Status=OK - 200
Date=Sun, 26 Jul 2009 10:11:35 GMT
Etag="ComputedETag"
Expires=Tue, 25 Aug 2009 10:11:35 GMT
So, I removed the line that sets no_local_copy in my PHP. This had no
impact on the way that the empty PHP document that sets no cache directives
was served, Apache never served erroneous 304 responses because it never
saw ETag or Last-Modified headers based on the PHP source. But the
ETag-conditional request for index.php by the browser now gives the correct
304 response code:
Status=Not Modified - 304
Date=Sun, 26 Jul 2009 10:16:23 GMT
Etag="ComputedETag1"
Expires=Tue, 25 Aug 2009 10:16:23 GMT
Reproduce code:
---------------
<?php
$etag="\"ComputedETag\"";
header("Etag: $etag");
//Expires ages away
header("Expires: " . gmdate("D, d M Y H:i:s", time()
+ 60 * 60 * 24 * 30) . " GMT");
if (isset($_SERVER['HTTP_IF_NONE_MATCH']) &&
$_SERVER['HTTP_IF_NONE_MATCH'] == $etag) {
/* At a users' request, the cache has been bypassed, but the
* document is still the same. Avoid costly response generation
* and waste of bandwidth by just sending not-modified.
* (it is illegal to send a response-body by the HTTP spec).
*/
header('HTTP/1.0 304 Not Modified');
error_log(date('r')." - Response: 304 Not Modified");
exit(); //Don't generate or send the body
}
error_log(date('r')." - Response: 200. Generated document.");
echo "Document body goes here";
?>
--
Edit bug report at http://bugs.php.net/?id=49106&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49106&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49106&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49106&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49106&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49106&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49106&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49106&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49106&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49106&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49106&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49106&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49106&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49106&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49106&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49106&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=49106&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49106&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49106&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49106&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49106&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49106&r=mysqlcfg
