The following reply was made to PR config/1649; it has been noted by GNATS.
From: Marc Slemko <[EMAIL PROTECTED]>
To: Apache bugs database <[EMAIL PROTECTED]>
Cc: Subject: config/1649: .htaccess is searched UNDER DocumentRoot (fwd)
Date: Tue, 20 Jan 1998 07:42:16 -0700 (MST)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to [EMAIL PROTECTED] for more info.
---559023410-1804928587-885306867=:7647
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <[EMAIL PROTECTED]>
---------- Forwarded message ----------
Date: Tue, 20 Jan 1998 16:34:27 +0200 (MET)
From: Aidas Kasparas <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: re: .htaccess is searched UNDER DocumentRoot
Dear Colleagues,
I know official state of this question is "closed" but I had problems
with this behavior, I made some changes and would like to share my
results.
Let's count:
o in standard installation with documents located in
/usr/local/etc/httpd/htdocs apache tries to open .htaccess file in 5
directories above the point where all documents are stored;
o in case of user www space (i.e. documents under
/home/user/public_html) 3 opens;
o in case of expert installation (i.e. /web/{cust1, cust2, ...,
custN} - 2 opens.
If in any of these paths indirect automounter map is involved (I
know - this is lame, but we do live in not perfect world) -
one risks to get his log filled with messages that system can't mount some
.htaccess files for the simple reason that they do not exist.
Are these files used in practice in these places? IMHO on 99.9% of
all servers - no (I may be wrong). The only use for them that comes to my
mind is configuring hierarchies like:
/web/
cheap_plan_cust/
.htaccess
cust11/
cust12/
....
expensive_plan_cust/
.htaccess
cust21/
cust22/
...
but even in this case it is possible to achieve required
functionality by inspecting only a limited number of directories above
corresponding document space (that could be configured at startup with
default to 0).
So my patch tries to force server start search of access files
from corresponding document root. It seams that it succeeds in case of
server documents or ~user files. But can fail if rewrite module or some
other module that maps URIs to filenames in funny way is in use. To handle
this correctly it is necessary to make more global changes to server code
(in particular - require that filename formation code separate path into
2 parts - document root and path within document space).
You are welcome to use this patch in any way but I am not
responsible for any consequences. I also will be happy to answer your
questions and discuss further about this problem.
Aidas
---559023410-1804928587-885306867=:7647
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="AK1.diff"
Content-Transfer-Encoding: BASE64
Content-ID: <[EMAIL PROTECTED]>
Content-Description: patch
SW5kZXg6IGFwYWNoZS9zcmMvaHR0cF9yZXF1ZXN0LmMNCj09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9hZG0va2FzcGFyL0NWUy9h
cGFjaGUvc3JjL2h0dHBfcmVxdWVzdC5jLHYNCnJldHJpZXZpbmcgcmV2aXNp
b24gMS4xLjEuMQ0KcmV0cmlldmluZyByZXZpc2lvbiAxLjMNCmRpZmYgLXIx
LjEuMS4xIC1yMS4zDQoyNTVjMjU1DQo8ICAgICBpbnQgbnVtX2RpcnMsIHJl
czsNCi0tLQ0KPiAgICAgaW50IG51bV9kaXJzLCBVUklfbnVtX2RpcnMsIHJl
czsNCjM0MWEzNDIsMzQ4DQo+ICAgICANCj4gICAgIA0KPiAgICAgLyoNCj4g
ICAgICAgIFdlIGRvbid0IG5lZWQgdG8gY2hlY2sgcHJlc2VuY2Ugb2YgLmh0
YWNjZXNzIGZpbGVzIA0KPiAgICAgICAgYWJvdmUgZG9jdW1lbnQgc3BhY2Ug
KGVpdGhlciBvZiBzZXJ2ZXIgb3Igb2YgdXNlcikuDQo+ICAgICAgICBXZSB0
cnkgdG8gbGltaXQgbnVtYmVyIG9mIGRpcmVjdG9yaWVzIGluc3BlY3RlZCB0
byANCj4gICAgICAgIG51bWJlcl9vZl9zbGFzaGVzX2luX1VSSS4NCjM0M2Mz
NTAsMzYyDQo8ICAgICBmb3IgKGkgPSAxOyBpIDw9IG51bV9kaXJzOyArK2kp
IHsNCi0tLQ0KPiAgICAgICAgQlVHOiBUaGlzIGNvZGUgc3RpbGwgY2hlY2sg
Lmh0YWNjZXNzIGZpbGVzIGFib3ZlIGRvY3VtZW50IHNwYWNlDQo+ICAgICAg
ICBpZiBvdGhlciBtb2R1bGVzIGludGVycHJldHMgVVJJJ3MgImRpcmVjdG9y
aWVzIiB0aGVpciBvd24gd2F5Lg0KPiAgICAgICAgQnV0IGFueXdheSB0aGVy
ZSB3aWxsIGJlIG5vIG1vcmUgY2hlY2tzIHRoYW4gaW4gb3JpZ2luYWwgdmVy
c2lvbi4NCj4gICAgICAgIFRvIGZpeCBpdCB3ZSBuZWVkIHRvIGZvcmNlIGFs
bCBmaWxlIHJld3JpdGluZyBtb2R1bGVzIHRvIHNlcGFyYXRlDQo+ICAgICAg
ICBwYXRocyB0byBkb2N1bWVudCBzcGFjZSBhbmQgd2l0aGluIGl0Lg0KPiAN
Cj4gICAgICAgIFBPVEVOVElBTCBGRUFUVVJFOiBGb3IgdGhvc2Ugd2hvIHJl
bGllZCBvbiBvbGQgYmVoYXZpb3IgaXQgaXMgDQo+ICAgICAgICBwb3NzaWJs
ZSB0byBtYWtlIGNvbmZpZ3VyYXRpb24gZGlyZWN0aXZlIENoZWNrc0Fib3Zl
RG9jU3BhY2UgdGhhdCANCj4gICAgICAgIHdpbGwgdGVsbCBob3cgbXVjaCBk
aXJlY3RvcmllcyB0byBjaGVjay4NCj4gICAgICAgIAkJCQkJCS0tQUsgKi8N
Cj4gICAgIFVSSV9udW1fZGlycyA9IGNvdW50X1VSSV9kaXJzKHItPnVyaSk7
DQo+IA0KPiAgICAgZm9yIChpID0gKFVSSV9udW1fZGlycyA8IG51bV9kaXJz
ICsxKT8gbnVtX2RpcnMgLSBVUklfbnVtX2RpcnMrMTogMSA7IGkgPD0gbnVt
X2RpcnM7ICsraSkgew0KSW5kZXg6IGFwYWNoZS9zcmMvdXRpbC5jDQo9PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvYWRtL2thc3Bh
ci9DVlMvYXBhY2hlL3NyYy91dGlsLmMsdg0KcmV0cmlldmluZyByZXZpc2lv
biAxLjEuMS4xDQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMg0KZGlmZiAtcjEu
MS4xLjEgLXIxLjINCjM3OWEzODAsMzk0DQo+IGludCBjb3VudF9VUklfZGly
cyhjb25zdCBjaGFyICpwYXRoKSB7DQo+ICAgICByZWdpc3RlciBpbnQgeCxu
Ow0KPiANCj4gICAgIGZvcih4PTAsbj0wO3BhdGhbeF07eCsrKXsNCj4gICAg
ICAgICBpZihwYXRoW3hdID09ICc/JykgYnJlYWs7DQo+ICAgICAgICAgaWYo
cGF0aFt4XSA9PSAnLycpIG4rKzsNCj4gICAgIH0NCj4gICAgIC8qIGEgaGFj
ayB0byB0YWtlIGludG8gYWNjb3VudCB1c2VycycgZGlyZWN0b3JpZXMgLS1B
SyAqLw0KPiAgICAgaWYgKCEqcGF0aCkgcmV0dXJuIG47DQo+ICAgICAvKiBu
b3cgaXQncyBzYWZlIHRvIGFjY2VzcyBzZWNvbmQgY2hhcmFjdGVyIC0tQUsg
Ki8NCj4gICAgIGlmIChwYXRoWzFdID09ICd+JykgcmV0dXJuIG4tMTsNCj4g
ICAgIHJldHVybiBuOw0KPiB9DQo+IA0KPiANCg==
---559023410-1804928587-885306867=:7647--