httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <>
Subject Apache documentation inadequate for order/allow/deny (fwd)
Date Sat, 19 Apr 1997 18:22:34 GMT

The first part hasn't been answered, but the 2nd part (user agent blocking)
has been..

---------- Forwarded message ----------
Date: Sat, 19 Apr 1997 01:25:31 +0100 (BST)
From: WWW server manager <>
Subject: Apache documentation inadequate for order/allow/deny

The Apache documentation (or at least, the obvious parts of it) fails to
specify the initial access control state.

Empirically (testing with Apache 1.2b8) the initial situation seems to be

 * all access allowed if "order deny,allow" used
 * all access denied if "order allow,deny" used

It is important that the initial state be stable and documented, otherwise
many reasonable access control configurations simply cannot be specified.
For example, a recent discussion here concerned a scenario where the 
requirement will be

 * access from *.x.y allowed, except that
 * access from specific (public-access) systems in *.x.y should be forbidden
 * access from outside *.x.y should be forbidden

With the facilities as currently documented - i.e. with initial state 
unspecified, there would be no way to achieve the required access controls:
it would be necessary to "allow from .x.y" but also to be able to "deny from 
all" (to block general access) and "deny from a.x.y b.x.y".

"Order deny,allow" would allow access from all *.x.y systems, while "Order 
allow,deny" would deny access from *all* systems.

This illustrates why it is critically important that the initial state be 
defined and documented. 

In addition to clarifying the documentation, I would be grateful if you could
confirm that the initial state is both as I've determined empirically and that
it is well-defined rather than being a chance feature of the way the code 
happens to work, not something to rely on.

On a different but related point, is there any prospect of allowing wildcards
in allow/deny? In the case that prompted my investigation, the local systems
to be excluded would at least in part by readily definable by wildcards, but
are not amenable to simple suffix matching, e.g. "deny from public*.x.y" is
what's really needed. 

Adding wildcard matching to the existing string matching seems superficially so
simple that I presume there must be some fundamental complication or ambiguity
which it would introduce ... True? Or is it just that there've always been
higher-priority features to add first?

                                John Line

PS While attempting to check the above with the source code (couldn't see how
it worked...), I noticed that 

allow from user-agents Lynx

(for example) is supported by the code but undocumented. Also some sort of
test on environment variables, though that either doesn't work or didn't test
what I thought it was testing... Out of curiosity, are these new features
planned for future release, or unsupported features that just happen to be 
lurking there for historical reasons? [No, I don't intend to start using them!
Could be useful for blocking access by a hypothetical especially badly behaved 
browser that really caused problems. Mmm... maybe good for getting rid of
especially obnoxious robots...?]

University of Cambridge WWW manager account (usually John Line)
Send general WWW-related enquiries to

View raw message