Comment # 8 on bug 939829 from Petr Gajdos

(In reply to Andrew Daugherity from comment #7)
> This happens if your are using mod_access_compat.  When that is enabled, you
> *must* use the 2.2 syntax and you'll get a 403 if trying to use the 2.4

*Generally*, that is not exactly true as far as I know. If both authz_core and
access_compat are loaded, you can use either system you want.

> Require ... syntax.  It might work to use both at once but that gets
> confusing (and possibly undefined if they conflict!).

You can even use both of them together, but the result has to be consistent,
that is: access is allowed if both systems allow. If at least one forbids,
access is forbidden. See 881506 comment 18.

> Because of this, relying on a version check is insufficient, as 2.4

Yes, thats true (because of access_compat), nevertheless ..

> w/mod_access_compat behaves like 2.2.  Adding wrappers like
> <IfModule mod_access_compat.c>
>   Order allow,deny
>   Allow from all
> </IfModule>
> <IfModule !mod_access_compat.c>
>   Require all granted
> </IfModule>

.. whether this will work depends also on which syntax is used previously. If
mod_access is loaded but new syntax forbid into this dir, this won't work. Also
note that access_compat is not present in sle11. So I would disclaim my comment
1 for distros older than Tumbleweed.

> e.g. default-server.conf.  I would suggest backporting the fix to 13.1/13.2,
> but that's beyond the scope of this bug, and the other one is closed, so ???

In my opinion, this is too invasive change to backport, I am afraid.

The situation on newly installed distros (not upgrades!) is as follows:

sle11
no access_compat
httpd.conf (Deny for /): old syntax

13.1
access_compat static
httpd.conf (Deny for /): new syntax

13.2
access_compat static
httpd.conf (Deny for /): new syntax

Tumbleweed
access_compat shared, not loaded by default
httpd.conf (Deny for /): old syntax when access_compat loaded, new syntax
otherwise

So everywhere in supported openSUSEs we can assume that new syntax should be
preferred. I tend to agree with Lars to use upstream solution. Currently I do
not se a way to catch all possibilities.