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:
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] [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]> ------------------------------------------------------------------------ [2002-10-17 19:27:08] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] Although, we need other patch, it seems the problem exists. ------------------------------------------------------------------------ [2002-10-14 11:00:55] [EMAIL PROTECTED] 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
