doc: limit_except

Gregg Reynolds dev at
Fri Mar 16 11:59:37 MSK 2007

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
                    -  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

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.



More information about the nginx mailing list