Access controls are normally effective for all access methods, and this is the usual desired behavior. In the general case, access control directives should not be placed within a <Limit> section.

The purpose of the <Limit> directive is to restrict the effect of the access controls to the nominated HTTP methods. For all other methods, the access restrictions that are enclosed in the <Limit> bracket will have no effect. The following example applies the access control only to the methods POST , PUT , and DELETE , leaving all other methods unprotected:

<Limit POST PUT DELETE>
 Require valid-user
</Limit>

The method names listed can be one or more of: GET , POST , PUT , DELETE , CONNECT , OPTIONS , PATCH , PROPFIND , PROPPATCH , MKCOL , COPY , MOVE , LOCK , and UNLOCK . The method name is case-sensitive. If GET is used, it will also restrict HEAD requests. The TRACE method cannot be limited (see TraceEnable ).

The <Limit> and <LimitExcept> directives may be nested. In this case, each successive level of <Limit> or <LimitExcept> directives must further restrict the set of methods to which access controls apply.

For example, given the following configuration, all users will be authorized for POST requests, and the Require group editors directive will be ignored in all cases:

<LimitExcept GET>
 Require valid-user
</LimitExcept>
<Limit POST>
 Require group editors
</Limit>