ID: 17098
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Apache2 related
Operating System: linux
PHP Version: 4.0CVS-2002-10-17
New Comment:
... and the bug is present in 4.3.0 release.
Previous Comments:
------------------------------------------------------------------------
[2002-12-25 18:03:55] [EMAIL PROTECTED]
... and it's not fixed in 4.3.0 RC4 either...
Daniel
------------------------------------------------------------------------
[2002-12-13 18:24:22] [EMAIL PROTECTED]
This bug is _NOT_ fixed in 4.3.0 rc3!
In 4.3.0, the apache2 support should not be experimental anymore, so I
think, this is a real showstopper IMHO.
I think, it's time to fix this issue now, it's so annoying and
unneccessary. If this patch has any known drawbacks that I'm not aware
of, then it's NOT the correct solution to simply ignore this subject as
whole.
Daniel
Here is the patch again as diff against php 4.3.0 rc 3:
--- sapi/apache2filter/sapi_apache2.c.old Thu Dec 12 21:48:58
2002
+++ sapi/apache2filter/sapi_apache2.c Thu Dec 12 21:50:43 2002
@@ -619,14 +619,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 = {
------------------------------------------------------------------------
[2002-12-03 09:28:16] [EMAIL PROTECTED]
Maybe I missed something. What patch? Is this still a php bug? I
have Apache 2.0.40 and php-4.4-2.
------------------------------------------------------------------------
[2002-10-18 06:34:46] [EMAIL PROTECTED]
I tried a patch submited by [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>
------------------------------------------------------------------------
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
