httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Redesigning <Limit > from the ground up.
Date Tue, 13 Feb 2007 20:00:09 GMT
As originally conceived, <Limit METH METH2> was designed to handle
a very limited (once 30, now 62) different possible methods and
assign them a specific Satisfy/Require/Allow/Deny/Order directive
pattern that otherwise has no corresponding value for the un-Limit'ed
method possibilities.  The model is fundamentally weak, and the side
effects of users believing their -other- directives were <Limit >'ed
or that they can have -multiple- <Limit >'ed constraints doesn't even
meet the principle of least surprise when there is no complaint at
startup.

I believe it needs to be scrapped.  <Limit > needs to become a first
class container for httpd directives.  Now, we must further confuse
an already confused situation.

Current per-dir merge order looks like

<Location "/abs"> (path order)
  <LocationMatch "pattern"> (directive order)
    <Directory "/abs"> (path order)
      <DirectoryMatch "pattern"> (directive order)
        <Files "foo"> (directive order)
          <Location "/abs"> (path order)
            <LocationMatch "pattern"> (directive order)

Yes, Locations are re-applied if you weren't aware of that.

So... Where does a Limit fall within this schema?

Should it be applied at the time of match of each of these sections
as they are struck?  Should it be a meta-control similar to <Location >
which is applied firstly and lastly?

Thoughts and observations are welcome as I begin to rough-in this
overhaul on trunk.

Bill


Mime
View raw message