| Summary: | timefmt config not working in SSI when using INCLUDES output filter and XBitHack On | ||
|---|---|---|---|
| Product: | Apache httpd-2 | Reporter: | Thomas Hadig <thadig> |
| Component: | mod_include | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bugzilla-apache, Edgar.Hoch, lars, phoenixcomm, zhangweiwu |
| Priority: | P2 | Keywords: | PatchAvailable |
| Version: | 2.2.3 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Attachments: |
Patch to not add the filter twice
Test for this problem alternative fix |
||
Hmm. My first guess is, that the INCLUDES filter is added twice (which is totally legal by itself, but perhaps not in this situtation) and these filters conflict somehow. Need to dig deeper. While experimenting with Apache 2.0 and 2.2 in preparation for an upgrade from 1.3, I as well ran into this bug. Some testing suggests that the bug may be related to content negotiation (yet, I'm not an Apache expert): - If I access a page not under content negotiation using the full URI, timefmt works. - If I access a page under content negotion using the full URI (e.g. "index.html.en" instead of "index.html" - i.e. skipping the negotiation) timefmt works. - If I access "/" (with only an "index.html" available) timefmt is ignored. - If I access a page under content negotiation without using the full URI (e.g. "index.html" instead of "index.html.en" or "index.html.dk" - i.e. leaving it up to the negotation to determine which file to display) timefmt is ignored. This is with Debian etch's default configuration, with the addition of "XBitHack on", and the executable bit set on the HTML files. I can confirm this on apache-2.2.3 on Gentoo. timefmt doesn't get parsed if a file is accessed through content negotiation. Accesses using the full URI or through a rewrite work just fine. *** Bug 32622 has been marked as a duplicate of this bug. *** Hard to believe this is now 2009 and this bug is discovered a lot of times without fix for several years. I hit this problem recently, and after a google search for workaround I found this bug is keep being reported in the recent 3 years (so it seems the problem started 3 years ago) Here are my finding of report of this bug on multiple forums: http://objectmix.com/apache/671983-ssi-config-timefmt-not-working-properly.html http://www.columbia.edu/acis/dev/unixdev/doc/www2-transition-issues.shtml#config (see the bottom of this page describe timefmt doesn't work in certain cases) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363964 (the bug report of the same issue on debian) http://markmail.org/message/74x5a67wdvsxqort (note this may not be the same bug) http://www.webmasterworld.com/apache/3574077.htm (a good bug report, state clearly for him this issue occurs only if x-bit is set) http://mail-archives.apache.org/mod_mbox/httpd-users/200403.mbox/%3c20040305105747.6408209f.shane@howsyournetwork.com%3e (this guy is quite clueless but found the issue) http://www.computing.net/answers/webdevel/ssi-config-timefmt-not-working/2708.html (in this case, the people who wanted to answer him is clueless) In my case, my gentoo linux installation ignore config timefmt if x-bit is set, for my ubuntu installation it ignores config timefmt whatever I do (all workarounds doesn't work, including: rename it to .shtml, remove the x-bit, refer to it directly in URI without content negotiation...) Is this reproducible in 2.2.9? I would wonder whether this is the same root-cause as bug 41960. Created attachment 23150 [details]
Patch to not add the filter twice
It does seem to be due to the filter getting added to the chain more than once. This patch for trunk fixes that for me.
*** Bug 46556 has been marked as a duplicate of this bug. *** Created attachment 23206 [details]
Test for this problem
This patch for the Apache test framework (trunk) adds a test that reproduces the problem, failing on trunk and 2.2.x right now, and passes on trunk after applying the fix patch from above.
Can someone else verify that this patch resolves the problem for them? Hi. I wish to test if the patch solves the problem but I am too dump to patch packages in Ubuntu Server. I used to do it in Gentoo with ease because it is a source-code-based distribution, but don't know how can I do it for Debian. Googling around it (things like builder's handbook) seems to be too complicated for me. If you can offer a debian package then I'd be glad to test... I have the following packages: $ aptitude search apache | grep ^i i apache2 - Next generation, scalable, extendable web i A apache2-mpm-prefork - Traditional model for Apache HTTPD i A apache2-utils - utility programs for webservers i A apache2.2-common - Next generation, scalable, extendable web i libapache2-mod-jk - Apache 2 connector for the Tomcat Java ser i libapache2-mod-perl2 - Integration of perl with the Apache2 web s i A libapache2-mod-php5 - server-side, HTML-embedded scripting langu i zimbra-apache - Best email money can buy (In reply to comment #12) > If you can offer a debian package then I'd be glad to test... Roughly: apt-get source apache2 apt-get build-dep apache2.2-common cd apache2-2* apply patch dpkg-buildpackage install the resulting pkg (In reply to comment #8) > Created an attachment (id=23150) [details] > Patch to not add the filter twice > > It does seem to be due to the filter getting added to the chain more than once. > This patch for trunk fixes that for me. > I'm having this problem as well, but the patch does not fix the issue for me. > This patch for the Apache test framework (trunk) adds a test that reproduces > the problem, failing on trunk and 2.2.x right now, and passes on trunk after > applying the fix patch from above. Sorry I couldn't understand what do you want me to do. I downloaded both httpd-2.2.10 source code and snapshot http://cvs.apache.org/snapshots/httpd/httpd_20090317091426.tar.gz and both cannot accept the patch. The file being patched to could not be found (e.g. "find . -iname include.conf.in" gives zero results for source extracted from both tar-ball. I could be too stupid to know how to patch apache (I patched a lot other software before, however). Can you give me a link what should I do in order to test your patch? From a gdb session: 1) yes, there are indeed two adjacent INCLUDES filters in the filter chain 2) at the time that handle_echo() evaluates the DATE_LOCAL variable, r->subprocess_env has DATE_LOCAL set to the LAZY_VALUE sentinel. 3) it then calls into add_include_vars_lazy() to set up DATE_LOCAL properly 4) add_include_vars_lazy() uses the default timefmt setting from the configuration -- ignoring any timefmt setting from the SSI script itself Unverified conjecture: (2) is happening because the second INCLUDES filter is coming in and nuking the DATE_LOCAL etc set up correctly when the first filter interpreted the "config timefmt" section. Avoiding multiple INCLUDES in a filter chain sounds kind of attractive but I'm not sure why such a configuration should be a explicitly forbidden. Fixing add_include_vars_lazy() to inherit the script's timefmt setting would seem to be an alternative fix for this. Indeed, add_include_vars() already takes ctx->time_str but ignores it. Created attachment 23391 [details]
alternative fix
This is an alternative fix which passes Dan's test case for me (thanks for that, Dan!).
Status update: Joe Orton committed fix to trunk http://svn.apache.org/viewvc?view=rev&revision=757376 Not yet proposed for backport. Backported to 2.2.x as r773352. *** Bug 30773 has been marked as a duplicate of this bug. *** Hi. As a stupid administrator who don't know about version control can you please hint since which version of 2.2.x release should I download and install on the production server that would contain this backport? Thanks in advance! (In reply to comment #21) > Hi. As a stupid administrator who don't know about version control can you > please hint since which version of 2.2.x release should I download and install > on the production server that would contain this backport? Thanks in advance! Get the latest. The changelog: http://www.apache.org/dist/httpd/CHANGES_2.2 shows it was in 2.2.12 and later. |
Using the following setup: in apache2.conf, default setting for handling shtml files): <FilesMatch "\.shtml(\..+)?$"> SetOutputFilter INCLUDES </FilesMatch> in Directory directive: <Directory /var/www/test> Options +Includes XBitHack On </Directory> following SSI code on a webpage: cat /var/www/test/foo.shtml <!--#config timefmt="%Y" --> Today is <!--#echo var="DATE_LOCAL" --> Web page is called .shtml and is executable: chmod +x /var/www/test/foo.shtml Output of this command is: Today is Thursday, 20-Apr-2006 12:34:11 PDT instead of correct Today is 2006 Thus, SSI statements are parsed but timefmt is ignored. Potential workarounds: - Remove XBitHack On - Replace shtml handling in apache2.conf with AddHandler server-parsed .shtml - Remove executable flag on web page - Rename web page to .html Note: The settings depend on the name of file containing the timefmt statement but the x bit of the file referenced in the URI. Example: User goes to http://localhost/test/foo2.html foo2.html has x bit set foo2.html contains: <!--#include virtual="foo.shtml" --> foo.shtml contains above example code but does NOT have the x bit set Problem still appears Note: Found one reference to the same or similar problem here: http://www.columbia.edu/acis/dev/unixdev/doc/www2-transition-issues.shtml#config