Return-Path: 
 <cvs-return-15625-apmail-httpd-cvs-archive=httpd.apache.org@httpd.apache.org>
Delivered-To: apmail-httpd-cvs-archive@httpd.apache.org
Received: (qmail 10359 invoked by uid 500); 21 Apr 2003 00:29:46 -0000
Mailing-List: contact cvs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
list-help: <mailto:cvs-help@httpd.apache.org>
list-unsubscribe: <mailto:cvs-unsubscribe@httpd.apache.org>
list-post: <mailto:cvs@httpd.apache.org>
Delivered-To: mailing list cvs@httpd.apache.org
Received: (qmail 10348 invoked by uid 500); 21 Apr 2003 00:29:45 -0000
Delivered-To: apmail-httpd-2.0-cvs@apache.org
Date: 21 Apr 2003 00:29:45 -0000
Message-ID: <20030421002945.73039.qmail@icarus.apache.org>
From: slive@apache.org
To: httpd-2.0-cvs@apache.org
Subject: cvs commit: httpd-2.0/docs/manual/mod core.xml
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

slive       2003/04/20 17:29:45

  Modified:    docs/manual/mod Tag: APACHE_2_0_BRANCH core.xml
  Log:
  Backport:
    Add note about when to use <location>.  This dupes what is already discussed
    in sections.html, but it is important enough to repeat.
  
  Revision  Changes    Path
  No                   revision
  
  
  No                   revision
  
  
  1.46.2.14 +18 -4     httpd-2.0/docs/manual/mod/core.xml
  
  Index: core.xml
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/mod/core.xml,v
  retrieving revision 1.46.2.13
  retrieving revision 1.46.2.14
  diff -u -d -b -u -r1.46.2.13 -r1.46.2.14
  --- core.xml	15 Apr 2003 22:56:31 -0000	1.46.2.13
  +++ core.xml	21 Apr 2003 00:29:44 -0000	1.46.2.14
  @@ -1700,10 +1700,24 @@
       <code>.htaccess</code> files are read, and after the <directive
       type="section" module="core">Files</directive> sections.</p>
   
  -    <p>Note that URLs do not have to line up with the filesystem at
  -    all, it should be emphasized that <directive
  -    type="section">Location</directive> operates completely
  -    outside the filesystem.</p>
  +    <p><directive type="section">Location</directive> sections operate
  +    completely outside the filesystem.  This has several consequences.
  +    Most importantly, <directive type="section">Location</directive>
  +    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.</p>
  +
  +    <note><title>When to use <directive 
  +    type="section">Location</directive></title>
  +
  +    <p>Use <directive type="section">Location</directive> to apply
  +    directives to content that lives outside the filesystem.  For
  +    content that lives in the filesystem, use <directive
  +    type="section" module="core">Directory</directive> and <directive
  +    type="section" module="core">Files</directive>.  An exception is
  +    <code>&lt;Location /&gt;</code>, which is an easy way to 
  +    apply a configuration to the entire server.</p>
  +    </note>
   
       <p>For all origin (non-proxy) requests, the URL to be matched is a
       URL-path of the form <code>/path/</code>.  No scheme, hostname,