From 936873ca8d2059efc05796697c0f90c238284351 Mon Sep 17 00:00:00 2001 From: Joshua Slive Date: Mon, 21 Apr 2003 00:24:28 +0000 Subject: [PATCH] Add note about when to use . This dupes what is already discussed in sections.html, but it is important enough to repeat. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@99467 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/mod/core.xml | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-) diff --git a/docs/manual/mod/core.xml b/docs/manual/mod/core.xml index 7fed697609..0b6de27d8f 100644 --- a/docs/manual/mod/core.xml +++ b/docs/manual/mod/core.xml @@ -1667,17 +1667,31 @@ URLs limits the scope of the enclosed directives by URL. It is similar to the Directory directive, and starts a subsection which is terminated with a - </Location> directive. </Location> directive. Location sections are processed in the order they appear in the configuration file, after the Directory sections and .htaccess files are read, and after the Files sections.

-

Note that URLs do not have to line up with the filesystem at - all, it should be emphasized that Location operates completely - outside the filesystem.

+

Location sections operate + completely outside the filesystem. This has several consequences. + Most importantly, Location + directives should not be used to control access to filesystem + locations. Since several different URLs may map to the same + filesystem location, such access controls may by circumvented.

+ + When to use <directive + type="section">Location</directive> + +

Use Location to apply + directives to content that lives outside the filesystem. For + content that lives in the filesystem, use Directory and Files. An exception is + <Location />, which is an easy way to + apply a configuration to the entire server.

+

For all origin (non-proxy) requests, the URL to be matched is a URL-path of the form /path/. No scheme, hostname, -- 2.40.0