doc: limit_except

Igor Sysoev is at
Fri Mar 16 12:17:44 MSK 2007

On Fri, Mar 16, 2007 at 02:59:37AM -0600, Gregg Reynolds wrote:

> On 3/16/07, Igor Sysoev <is at> wrote:
> >
> >May be "restrict_methods_except" ? Note, that directive should certainly
> >speсify unrestricted methods.
> >
> >And I do not want to use it for authorization only.
> I wonder if we're talking about the same thing.  I mean only to
> observe that the semantics of limit_except and the directives within
> its scope all have something to do with authorization.  Consider:
>   allow/deny  -  authorization granted/denied based on ipaddr
>   auth_basic
>   auth_basic_user_file
>                    -  authorization granted/denied based on user identity
>   proxy_pass  -  authorization granted absolutely (??)
>   perl   -  authorization granted absolutely (??)
> Or have I misunderstood the design intention?  The last two items
> don't really seem to control authorization so much as selection of a
> mechanism or routing.  E.g. proxy_pass in a limit_except means "use
> this proxy for messages with this method".
> Is that the idea?
> The Apache documentation uses the term "access control directives" to
> describe the contents of LimitExcept.  That won't quite work with
> nginx, since proxy_pass and perl aren't themselves access controllers.
> Correct?  That argues strongly for a name that differs from
> LimitExcept, so as to avoid giving the impression that the semantics
> are the same.
> "restrict_methods_except" - I'll have to ponder that.  "Restrict" is a
> preferable to "limit", IMO.  On the other hand, it leaves the
> impression that the enclosed directives are restrictions, which isn't
> quite accurate.  Also the combination of either limit or restrict with
> "except" - to me that clouds the logic - we have args, and we have the
> block, to which do these things apply?  The name should ideally make
> it obvious.  I think the trouble (for me) is that limit_except
> combines things from different categories, so it's hard to name
> accurately.
> BTW if I go on a bit about stuff like this it's not because I'm
> religious about what ends up in the syntax.  I just like the writing
> challenge of finding le mot juste.

The initial purpose of "limit_except" was to allow the DAV methods
for trusted addresses:

        location / {
            root                   /data/www;

            dav_methods  PUT DELETE MKCOL COPY MOVE;

            limit_except  GET {
                deny   all;

Apache initially has the "Limit" directive only:

        <Limit   PUT  DELETE>

Then it became clear that number of methods will grow and it's much secure
to specify general methods than restricted methods, so the "LimitExcept"
directive appeared.

Although initially "limit_except" was used for authorization only,
now it allows two non-authorization directive - "proxy_pass" and "perl"
and can be use as method switches as well as "location"s are used as
URI swicther. If I will make support of several "limit_except" blocks
the directive should be even renamed to "methods_except":

         location / {

              methods    POST {
                   proxy_pass ...

              methods    LOCK  UNLOCK {
                   perl  ...

              methods_except    GET {

              # GET/HEAD

Igor Sysoev

More information about the nginx mailing list