Roy T. Fielding wrote:

IIRC, trunk contains (or contained) a security problem with regard to
backward compatibility with 2.x configs.  I won't consider it releasable
until that has been fixed one way or another, and I can't tell from this
mail thread whether the actual fix was committed or not.

  This posting might answer some of your questions:

http://marc.info/?l=apache-httpd-dev&m=122573959206980&w=2

  Yes, the "fix" was committed, and the current intention is that 2.2
configurations should be useable as-is with trunk, without changes.
I don't think I can *promise* that's working as intended, but that's
the idea; if you encounter bugs, please report them!


   AuthzMergeRules Off

still appears in docs/conf/httpd.conf:162-167 even though it doesn't
appear to be a valid config directive either.

  This should be gone in httpd.conf.in; there's no httpd.conf in SVN.
Is there any chance you need to refresh from SVN trunk?


The docs seem to indicate this is now MergeAuthz Off and is off by
default?  Is that true in the code?

  Yes, that's the intention; again, please report bugs or backwards-
compatibility problems.


(why those
directive names are Match* instead of AuthMatch* boggles my mind).

What is the conclusion to this thread?  Why are all the Authz
directives given random names?  Am I the only one that finds this
feature set impossible to follow?

  Please see the final set of comments in the posting I linked to
above, and the patch in that posting as well.  Just to reiterate,
what I wrote there was:

   Finally there was a certain amount of bike-shed re-painting in
the form of renaming configuration directives.  I settled on
Match, <MatchAll>, etc. based on Eric Covener's comments.

   If people dislike those names, please jump in and change them.
Or if most folks think we'd be better off without authz containers
entirely, please vote for the following patch, which simply turns all
that stuff off, leaving (I hope) a fairly clean core authz implementation
that supports default 2.2-style behaviour and is extensible down the road,
should that be desired.


Chris.

--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B

Reply via email to