Yasuo Ohgaki wrote:
> Ilia A. wrote:
> >>Summary: Apache2 sending 304 - not modified header
> >>http://bugs.php.net/bug.php?id=17098
> >>
> >>This is serious problem for serious sites.
> >>(Serious sites shouldn't use Apache2, though)
> >
> >
> > This looks like an Apache 2 bug, rather then aPHP one. I am guessing the fix
> > they made did not work properly.
>
> Great!
> Then we can just wait their fix :)
I am afraid this is not the case. This is the report of the status.
As from Apache 2.0.40, the API of the filter registration functions
has changed. The changelog says:
--- From Apache Changelog: in section "Changes with Apache 2.0.40" ---
*) 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]
--- End quotation from Apache Changelog ---
And the current mod_include.c in Apache 2.0.43 source tree uses this
API like this:
--- From modules/filters/mod_include.c in Apache 2.0.43 source tree ---
static int includes_setup(ap_filter_t *f)
{
include_dir_config *conf =
(include_dir_config *)ap_get_module_config(f->r->per_dir_config,
&include_module);
/* When our xbithack value isn't set to full or our platform isn't
* providing group-level protection bits or our group-level bits do not
* have group-execite on, we will set the no_local_copy value to 1 so
* that we will not send 304s.
*/
if ((*conf->xbithack != xbithack_full)
|| !(f->r->finfo.valid & APR_FINFO_GPROT)
|| !(f->r->finfo.protection & APR_GEXECUTE)) {
f->r->no_local_copy = 1;
}
return OK;
}
/* Note from TAKAGI: several lines omitted */
static void register_hooks(apr_pool_t *p)
{
APR_REGISTER_OPTIONAL_FN(ap_ssi_get_tag_and_value);
APR_REGISTER_OPTIONAL_FN(ap_ssi_parse_string);
APR_REGISTER_OPTIONAL_FN(ap_register_include_handler);
ap_hook_post_config(include_post_config, NULL, NULL, APR_HOOK_REALLY_FIRST);
ap_hook_fixups(include_fixup, NULL, NULL, APR_HOOK_LAST);
ap_register_output_filter("INCLUDES", includes_filter, includes_setup,
AP_FTYPE_RESOURCE);
}
--- End quotation from modules/filters/mod_include.c ---
And Justin Erenkrantz himself stated in the email as follows:
http://www.phpbuilder.com/mail/php-developer-list/2002062/0392.php
"I will try to work on a more complete fix for PHP this weekend
as it is susceptable to the same invalid 304 problem mod_include
was. (Just create a simple filter_init function that always sets
r->no_local_copy to 1.)"
So, I do believe that some modification is necessary where the
sapi/apache2filter/sapi_apache2.c calls API functions
ap_register_{input|output}_filter(...). What I am not sure is whether it
is necessary to modify both the "input" and "output" functions or not.
To reproduce the problem:
The script:
--- Script test.phtml ---
<?php
$fmt = filemtime ( $_SERVER [ 'SCRIPT_FILENAME' ] ) ;
$ludate = $fmt + 600 ;
header ( "content-type: text/html; charset=ISO-8859-1" ) ;
header ( "Last-Modified: " . gmdate ( 'D, d M Y H:i:s \G\M\T', $ludate ) ) ;
print ( "<html><head><title>Test</title></head><body>\n" ) ;
print ( "File timestamp: " . gmdate ( 'D, d M Y H:i:s \G\M\T', $fmt ) ) ;
print ( "<br>" ) ;
print ( "Last updated: " . gmdate ( 'D, d M Y H:i:s \G\M\T', $ludate ) ) ;
print ( "</body></html>\n" ) ;
?>
--- End script ---
Set the timestamp of the script file properly.
If you access the script using a browser, it displays:
--- Browser displays ---
File timestamp: Fri, 18 Oct 2002 09:00:00 GMT
Last updated: Fri, 18 Oct 2002 09:10:00 GMT
--- End browser displays ---
Access the server using "telnet":
--- Telnet servername http requests and results before patch ---
[rt@ns rt]$ telnet localhost http
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD /test.phtml HTTP/1.1
Host: localhost.localdomain
HTTP/1.1 200 OK
Date: Fri, 18 Oct 2002 09:22:11 GMT
Server: Apache/2.0.43 (Unix) mod_ssl/2.0.43 OpenSSL/0.9.6g PHP/4.3.0-dev
Accept-Ranges: bytes
X-Powered-By: PHP/4.3.0-dev
Last-Modified: Fri, 18 Oct 2002 09:10:00 GMT
Content-Type: text/html; charset=ISO-8859-1
HEAD /test.phtml HTTP/1.1
Host: localhost.localdomain
If-Modified-Since: Fri, 18 Oct 2002 08:59:00 GMT
HTTP/1.1 200 OK
Date: Fri, 18 Oct 2002 09:22:21 GMT
Server: Apache/2.0.43 (Unix) mod_ssl/2.0.43 OpenSSL/0.9.6g PHP/4.3.0-dev
Accept-Ranges: bytes
X-Powered-By: PHP/4.3.0-dev
Last-Modified: Fri, 18 Oct 2002 09:10:00 GMT
Content-Type: text/html; charset=ISO-8859-1
HEAD /test.phtml HTTP/1.1
Host: localhost.localdomain
If-Modified-Since: Fri, 18 Oct 2002 09:01:00 GMT
HTTP/1.1 304 Not Modified
Date: Fri, 18 Oct 2002 09:22:41 GMT
Server: Apache/2.0.43 (Unix) mod_ssl/2.0.43 OpenSSL/0.9.6g PHP/4.3.0-dev
ETag: "8598-1e2-ca628400"
--- End Telnet ---
As is evident in the last response from the server, the
If-Modified-Since: header is not properly processed.
After the patch is applied, the problem disappears:
--- Telnet servername http requests and results after patch ---
[rt@ns rt]$ telnet localhost http
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD /test.phtml HTTP/1.1
Host: localhost.localdomain
HTTP/1.1 200 OK
Date: Fri, 18 Oct 2002 09:18:00 GMT
Server: Apache/2.0.43 (Unix) mod_ssl/2.0.43 OpenSSL/0.9.6g PHP/4.3.0-dev
Accept-Ranges: bytes
X-Powered-By: PHP/4.3.0-dev
Last-Modified: Fri, 18 Oct 2002 09:10:00 GMT
Content-Type: text/html; charset=ISO-8859-1
HEAD /test.phtml HTTP/1.1
Host: localhost.localdomain
If-Modified-Since: Fri, 18 Oct 2002 09:09:00 GMT
HTTP/1.1 200 OK
Date: Fri, 18 Oct 2002 09:18:19 GMT
Server: Apache/2.0.43 (Unix) mod_ssl/2.0.43 OpenSSL/0.9.6g PHP/4.3.0-dev
Accept-Ranges: bytes
X-Powered-By: PHP/4.3.0-dev
Last-Modified: Fri, 18 Oct 2002 09:10:00 GMT
Content-Type: text/html; charset=ISO-8859-1
--- End Telnet ---
The test result was obtained using CVS 20021018 (today's one). The
system used is Red Hat Linux 6.2.
Regards
Ryo
--
R Takagi <[EMAIL PROTECTED]>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
