On Tue, 13 Feb 2007 14:00:09 -0600 "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote:
> 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. The fundamental weakness of <Limit> is that it requires a module to cooperate proactively, and many modules don't. That gives it different semantics to other standard containers. > 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. I disagree. <Limit> is far too firmly established to change its semantics. Either we keep it as-is (warts and all) or we scrap it, and generate a startup error that advises the user of alternatives. One possible replacement would be to make it an optional argument to <Directory> & family: <Location /limited/ methods="GET POST HEAD"> </Location> I haven't thought through the implementation details of that, but the semantics work, and I think they'd deal with your concerns. Now, if we were to rework containers, it might be time to bring in some kind of if-then-else logic (the road <LimitExcept> started down): <Location /limited/ method="GET POST HEAD"> <Else Location /limited/ method!="GET POST HEAD"> </Location> That's far too ugly as stated, but you get the idea. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
