Created attachment 29445 [details] necessary files to reproduce the problem in zip arch I have a site with gzipped css files. They are given to the client, depending on Accept-encoding header. > cat .htaccess RewriteEngine On RewriteBase / > cat css/.htaccess RewriteEngine On ### RewriteBase /css/ RewriteCond %{HTTP:Accept-encoding} gzip RewriteCond %{REQUEST_FILENAME}.gz -f RewriteRule ^(.*)$ $1.gz [QSA,L] > ls -a css/ .htaccess site.css site.css.gz After update from 2.2.22 to 2.2.23 this mechanism has broken. Test case in attachment. Test URL: http://charlie.aha.ru/css/site.css I got error "The requested URL /site.css.gz was not found on this server." instead of css/site.css.gz file content. Note the string "URL /site.css.gz" - looks like apache missing directory "css" from the path. If I remove "RewriteBase /" from parent .htaccess, I get gzipped css file. Or, if I add string "RewriteBase /css/" into ./css/.htaccess, I get gzipped css file. So it looks like "RewriteBase /" is inherited now from top .htaccess. When I did rollback to 2.2.22 everything became ok. Is it bug or is it feature?
By the way.. I have reports from Joomla users with SEO enabled. Links oh these sites becomes dead, with "RewriteBase /" string in the .htaccess
This is via http://svn.apache.org/viewvc?view=revision&revision=1032431 which got wrapped up in a backport for a followon to another regression.
Charlie, http://people.apache.org/~rjung/patches/rewriteoption-mergebase-2_2.patch should be the fix to the bug you observed. We are just about rolling 2.2.24 today when the 'fix was fixed', so I'm wondering if you have time to confirm the fix right away?
yes, I confirmed that patch fixes the bug. I've tested this patch on apache 2.2.23 about two days, everything works fine.
Sorry, but one more question: the patch as referred to above was only produced today. I assume you tested the previous version which was committed to 2.4 before today: http://svn.apache.org/viewvc?view=revision&revision=1418954 Any chance you can do a quick test for the final patch http://people.apache.org/~rjung/patches/rewriteoption-mergebase-2_2.patch The difference is: if the RewriteOption MergeBase is *not* set, then the old patch will not allow to set a RewriteBase in a sub directory (it will be ignored). The newer one allows to set one, it does only inhibit the inheritance if none is set explicitly. Thanks! Rainer
I've been noticed some weeks ago by bugzilla, what PR 53963 was fixed in trunk, and made patch for 2.2.23 using this revision: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/mappers/mod_rewrite.c?r1=1369999&r2=1410681 - it is replica of revision 1418954 regarding to changes in mod_rewrite.c After testing it I've found bug in that fix, found how to fix it and emailed to Eric Covener about it. Today's 'fix for fix' (http://svn.apache.org/viewvc?diff_format=h&view=revision&revision=1447448) was contributed by me (Evgeny Barsukov) :) So, my patch for mod_rewrite.c is exactly looks like rewriteoption-mergebase-2_2.patch: http://charlie.aha.ru/patch-modules-mappers_mod_rewrite.c
Great, thanks for the explanation. So we are good to go :)
Fixed in 2.2.24 and 2.4.4