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