ID: 17098
Comment by: alex@taylexson.org
Reported By: pmoor@netpeople.ch
Status: Analyzed
Bug Type: Apache2 related
Operating System: linux
PHP Version: 4.0CVS-2002-10-17
New Comment:
Maybe I missed something. What patch? Is this still a php bug? I
have Apache 2.0.40 and php-4.4-2.
Previous Comments:
------------------------------------------------------------------------
[2002-10-18 06:34:46] mammal@vol.cz
I tried a patch submited by rt@takagi-ryo.ac
and it seems to solve the problem. I don't know to what extent, but the
logic of it seems ok to me...
------------------------------------------------------------------------
[2002-10-18 05:43:08] yohgaki@php.net
Ok. We should do something about this bug, I suppose.
Mail from Ryou Takagi
========= BEGIN ========
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 <rt@takagi-ryo.ac>
------------------------------------------------------------------------
[2002-10-17 19:27:08] yohgaki@php.net
It would be Apache2 bug
------------
On October 17, 2002 07:06 pm, Yasuo Ohgaki wrote:
> Andrei Zmievski wrote:
> > Hi,
> >
> > We have 10 critical bugs in the list currently. If you could please
see
> > about fixing at least one of them, we'd be that much closer to a
release
> > candidate.
>
> 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.
Ilia
------------------------------------------------------------------------
[2002-10-17 17:54:43] yohgaki@php.net
Although, we need other patch, it seems the problem exists.
------------------------------------------------------------------------
[2002-10-14 11:00:55] rt@takagi-ryo.ac
This is still not fixed... PHP code needs modifying.
I have tried PHP 4.2.3 and 4.3.0-pre1 with Apache 2.0.43
running on RedHat 6.2, and it still returns erroneous 304s.
The following is what I 'borrowed' from the Apache's
mod_include.c, which seems working within PHP 4.2.3.
--- sapi/apache2filter/sapi_apache2.c~ Fri Aug 16 07:27:03 2002
+++ sapi/apache2filter/sapi_apache2.c Mon Oct 14 23:27:26 2002
@@ -558,14 +558,24 @@
return OK;
}
+static int includes_setup(ap_filter_t *f)
+{
+ /* We will ALWAYS set the no_local_copy value to 1 so
+ * that we will not send 304s.
+ */
+ f->r->no_local_copy = 1;
+
+ return OK;
+}
+
static void php_register_hook(apr_pool_t *p)
{
ap_hook_pre_config(php_pre_config, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_post_config(php_apache_server_startup, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_insert_filter(php_insert_filter, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_post_read_request(php_post_read_request, NULL, NULL,
APR_HOOK_MIDDLE);
- ap_register_output_filter("PHP", php_output_filter, NULL,
AP_FTYPE_RESOURCE);
- ap_register_input_filter("PHP", php_input_filter, NULL,
AP_FTYPE_RESOURCE);
+ ap_register_output_filter("PHP", php_output_filter,
includes_setup, AP_FTYPE_RESOURCE);
+ ap_register_input_filter("PHP", php_input_filter,
includes_setup, AP_FTYPE_RESOURCE);
}
AP_MODULE_DECLARE_DATA module php4_module = {
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/17098
--
Edit this bug report at http://bugs.php.net/?id=17098&edit=1