You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2007/02/13 21:00:09 UTC
Redesigning from the ground up.
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
Re: Redesigning from the ground up.
Posted by Joshua Slive <jo...@slive.ca>.
On 2/13/07, Nick Kew <ni...@webthing.com> wrote:
> > > <Location /limited/ methods="GET POST HEAD">
I like that a lot. It makes it clear that methods is an option (and
hence doesn't generally need to be there), and skirts the whole
ordering mess you get by adding a <Method> container.
> <Directory /dir/> --> <Section filepath = /dir/>
> <Location /loc/> --> <Section urlpath = /loc/>
> <Files pattern> --> <Section relpath = pattern>
> <FilesMatch regex> --> <Section relpath ~ regex>
> <Limit GET POST> --> <Section methods = "GET POST">
> ... etc ...
>
> Generalising to <Section somepath=... methods=...>,
> and to support things like negation.
>
> Possibly also drop the confusingly markup-like syntax:
>
> BEGIN filepath=/dir/
> ...
> END
I hate all that.
Although <Location>/<Directory>/etc are certainly confusing, I don't
see how the above is that much clearer. People are still going to
need to read the docs to understand what urlpath and filepath mean.
And how does the ordering work? And can you arbitrarily combine
filepath/relpath/methods/etc in the same section? Just a big mess, as
far as I can tell.
And I don't see any point in making massive changes to the config-file
format unless there are large concrete gains to be had. It is not
only a question of converting old config files to the new format.
More difficult is retraining everyone who knows and loves (or hates)
the old format.
Incremental improvements are great!
Joshua.
Re: Redesigning from the ground up.
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 13 Feb 2007 15:46:38 -0600
"William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
> > 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.
>
> Well, I'm proposing this for now to 2.4.
Well, it couldn't be anything earlier than that!
> > 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 that's an interesting idea. I'll consider that.
>
> Within the construct of the original suggestion, what if <Limit > in
> my proposed form became <Method[s] >? Would that help to disambiguate
> the two?
Yes, but it still feels confusing. Going back to your first post,
I think that's why the 'right' semantics aren't obvious.
Come to think of it, there's a lot of confusion about
<Directory> vs <Location> in luser-land. We have it
documented, but only those with braincells read that.
Perhaps this could benefit from a ganeral overhaul
<Directory /dir/> --> <Section filepath = /dir/>
<Location /loc/> --> <Section urlpath = /loc/>
<Files pattern> --> <Section relpath = pattern>
<FilesMatch regex> --> <Section relpath ~ regex>
<Limit GET POST> --> <Section methods = "GET POST">
... etc ...
Generalising to <Section somepath=... methods=...>,
and to support things like negation.
Possibly also drop the confusingly markup-like syntax:
BEGIN filepath=/dir/
...
END
Design goals:
- An old config can be programatically updated
(and we ship a perl script to do it).
- No source-incompatibility with 2.0/2.2 modules
- API for modules to add their own arguments
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: Redesigning from the ground up.
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Nick Kew wrote:
> On Tue, 13 Feb 2007 14:00:09 -0600
> "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
>
> 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.
Yes, that is correct, most modules don't, and are silent when their
directives are apparently (but not actually) <Limit >ed.
>> 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.
Well, I'm proposing this for now to 2.4.
> 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 that's an interesting idea. I'll consider that.
Within the construct of the original suggestion, what if <Limit > in
my proposed form became <Method[s] >? Would that help to disambiguate
the two?
> 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.
It might be interesting. But, I think we can proceed with either the
<Method[s] > or method= argument to Location, Directory and Files and
resolve an Else-syntax later.
Re: Redesigning from the ground up.
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 13 Feb 2007 14:00:09 -0600
"William A. Rowe, Jr." <wr...@rowe-clan.net> 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/