Bug 53963 - RewriteBase inherited now?
Summary: RewriteBase inherited now?
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_rewrite (show other bugs)
Version: 2.2.23
Hardware: PC All
: P2 normal with 6 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: FixedInTrunk
Depends on:
Reported: 2012-10-04 11:07 UTC by charlie
Modified: 2013-03-03 16:41 UTC (History)
1 user (show)

necessary files to reproduce the problem in zip arch (747 bytes, application/octet-stream)
2012-10-04 11:07 UTC, charlie

Note You need to log in before you can comment on or make changes to this bug.
Description charlie 2012-10-04 11:07:52 UTC
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?
Comment 1 charlie 2012-10-04 13:30:40 UTC
By the way.. I have reports from Joomla users with  SEO enabled. Links oh these sites becomes dead, with "RewriteBase /" string in the .htaccess
Comment 2 Eric Covener 2012-10-04 16:29:13 UTC
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.
Comment 3 William A. Rowe Jr. 2013-02-18 20:52:39 UTC


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?
Comment 4 charlie 2013-02-18 21:15:26 UTC
yes, I confirmed that patch fixes the bug. I've  tested this patch on apache 2.2.23 about two days, everything works fine.
Comment 5 Rainer Jung 2013-02-18 21:29:07 UTC
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:


Any chance you can do a quick test for the final 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.


Comment 6 charlie 2013-02-18 21:58:21 UTC
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:
Comment 7 Rainer Jung 2013-02-18 22:15:50 UTC
Great, thanks for the explanation.
So we are good to go :)
Comment 8 Stefan Fritsch 2013-03-03 16:41:21 UTC
Fixed in 2.2.24 and 2.4.4