You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by dg...@hyperreal.org on 1998/03/06 10:37:11 UTC

cvs commit: apache-1.3/htdocs/manual/mod core.html

dgaudet     98/03/06 01:37:11

  Modified:    src      CHANGES
               src/main http_request.c
               htdocs/manual upgrading_to_1_3.html
               htdocs/manual/mod core.html
  Log:
  Change to the multiple-slash behaviour of LocationMatch for consistency
  with AliasMatch and RewriteRule.  This was discussed in nh.9711, search
  for subject "mod_rewrite/1440".  My proposed change had the support of
  Roy, Ken and Dirk... I modified it slightly here so that it wouldn't
  break every single existing config that has <Location /server-status>.
  
  PR:		1440
  
  Revision  Changes    Path
  1.691     +10 -0     apache-1.3/src/CHANGES
  
  Index: CHANGES
  ===================================================================
  RCS file: /export/home/cvs/apache-1.3/src/CHANGES,v
  retrieving revision 1.690
  retrieving revision 1.691
  diff -u -r1.690 -r1.691
  --- CHANGES	1998/03/06 08:51:58	1.690
  +++ CHANGES	1998/03/06 09:37:04	1.691
  @@ -1,5 +1,15 @@
   Changes with Apache 1.3b6
   
  +  *) Change to Location and LocationMatch semantics.  LocationMatch no
  +     longer lets a single slash match multiple adjacent slashes in the
  +     URL.  This change is for consistency with RewriteRule and
  +     AliasMatch.  Multiple slashes have meaning in URLs that they do
  +     not have in (some) filesystems.  Location on the other hand can
  +     be considered a shorthand for a more complicated regex, and it
  +     does match multiple slashes with a single slash -- which is
  +     also consistent with the Alias directive.
  +     [Dean Gaudet] related PR#1440
  +
     *) Fix bug with mod_mime_magic causing certain files, including files
        of length 0, to result in no response from the server.
        [Dean Gaudet]
  
  
  
  1.111     +12 -7     apache-1.3/src/main/http_request.c
  
  Index: http_request.c
  ===================================================================
  RCS file: /export/home/cvs/apache-1.3/src/main/http_request.c,v
  retrieving revision 1.110
  retrieving revision 1.111
  diff -u -r1.110 -r1.111
  --- http_request.c	1998/03/06 08:26:18	1.110
  +++ http_request.c	1998/03/06 09:37:06	1.111
  @@ -509,13 +509,18 @@
   	return OK;
       }
   
  -    /*
  -     * Collapse multiple slashes, if it's a path URL (we don't want to do
  -     * anything to <Location http://...> or such).
  +    /* Location and LocationMatch differ on their behaviour w.r.t. multiple
  +     * slashes.  Location matches multiple slashes with a single slash,
  +     * LocationMatch doesn't.  An exception, for backwards brokenness is
  +     * absoluteURIs... in which case neither match multiple slashes.
        */
  -    test_location = pstrdup(r->pool, r->uri);
  -    if (test_location[0] == '/')
  -        no2slash(test_location);
  +    if (r->uri[0] != '/') {
  +	test_location = r->uri;
  +    }
  +    else {
  +	test_location = pstrdup(r->pool, r->uri);
  +	no2slash(test_location);
  +    }
   
       /* Go through the location entries, and check for matches. */
   
  @@ -535,7 +540,7 @@
   	this_conf = NULL;
   
   	if (entry_core->r) {
  -	    if (!regexec(entry_core->r, test_location, 0, NULL, 0))
  +	    if (!regexec(entry_core->r, r->uri, 0, NULL, 0))
   		this_conf = entry_config;
   	}
   	else if (entry_core->d_is_fnmatch) {
  
  
  
  1.14      +5 -1      apache-1.3/htdocs/manual/upgrading_to_1_3.html
  
  Index: upgrading_to_1_3.html
  ===================================================================
  RCS file: /export/home/cvs/apache-1.3/htdocs/manual/upgrading_to_1_3.html,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- upgrading_to_1_3.html	1998/02/18 10:00:57	1.13
  +++ upgrading_to_1_3.html	1998/03/06 09:37:07	1.14
  @@ -77,7 +77,7 @@
        AuthName "This and That"
       </PRE>
       </P>
  -    This change was made for HTTP/1.1 compliance.
  +    This change was made for consistency in the config language.
     <LI><STRONG>The default Apache ServerRoot directory changed</STRONG>
       from the NCSA-compatible <SAMP>/usr/local/etc/httpd/</SAMP> to
       <SAMP>/usr/local/apache/</SAMP>. This change covers only the default
  @@ -131,6 +131,10 @@
        inconsistancies, and was removed.  To emulate this older behaviour
        use a &lt;Files&gt; section nested inside a &lt;Directory&gt;
        section.
  +
  +  <li>&lt;Location&gt; matching behaviour with respect to slashes has
  +     changed.  See the <a href="mod/core.html#location">&lt;Location&gt;
  +     documentation</a> for more info.
   
   </UL>
   
  
  
  
  1.104     +40 -16    apache-1.3/htdocs/manual/mod/core.html
  
  Index: core.html
  ===================================================================
  RCS file: /export/home/cvs/apache-1.3/htdocs/manual/mod/core.html,v
  retrieving revision 1.103
  retrieving revision 1.104
  diff -u -r1.103 -r1.104
  --- core.html	1998/02/20 06:52:03	1.103
  +++ core.html	1998/03/06 09:37:08	1.104
  @@ -1312,35 +1312,42 @@
   1.1 and later.<P>
   
   <P>The &lt;Location&gt; directive provides for access control by
  -URL. It is comparable to the <A
  +URL. It is similar to the <A
   HREF="#directory">&lt;Directory&gt;</A> directive, and
  -should be matched with a &lt;/Location&gt; directive. Directives that
  -apply to the URL given should be listed
  -within. <CODE>&lt;Location&gt;</CODE> sections are processed in the
  +starts a subsection which is terminated with a &lt;/Location&gt;
  +directive.  <CODE>&lt;Location&gt;</CODE> sections are processed in the
   order they appear in the configuration file, after the
   &lt;Directory&gt; sections and <CODE>.htaccess</CODE> files are
  -read.</P>
  +read, and after the &lt;Files&gt; sections.</P>
   
  -<P>Note that, due to the way HTTP functions, <EM>URL prefix</EM>
  -should, save for proxy requests, be of the form <CODE>/path/</CODE>,
  -and should not include the <CODE>http://servername</CODE>. It doesn't
  -necessarily have to protect a directory (it can be an individual
  -file, or a number of files), and can include wild-cards.  In a wild-card
  -string, `?' matches any single character, and `*' matches any
  -sequences of characters.
  +<p>Note that URLs do not have to line up with the filesystem at all,
  +it should be emphasized that &lt;Location&gt; operates completely outside
  +the filesystem.
  +
  +<p>For all origin (non-proxy) requests, the URL to be matched is
  +of the form <code>/path/</code>, and you should not include any
  +<code>http://servername</code> prefix.  For proxy requests, the URL
  +to be matched is of the form <code>scheme://servername/path</code>,
  +and you must include the prefix.
  +
  +<p>The URL may use wildcards In a wild-card string, `?' matches any
  +single character, and `*' matches any sequences of characters.
   
   <P><STRONG>Apache 1.2 and above:</STRONG>
   Extended regular expressions can also be used, with the addition of
  -the
  -<CODE>~</CODE> character. For example:</P>
  +the <CODE>~</CODE> character.
  +
  +For example:</P>
   
   <PRE>
      &lt;Location ~ &quot;/(extra|special)/data&quot;&gt;
   </PRE>
   
   <P>would match URLs that contained the substring "/extra/data" or
  -"/special/data". However, in Apache 1.3 and above, use of <A
  -HREF="#locationmatch">&lt;LocationMatch&gt;</A> is preferred.</P>
  +"/special/data".  In Apache 1.3 and above, a new directive
  +<A HREF="#locationmatch">&lt;LocationMatch&gt;</A> exists which
  +behaves identical to the regex version of
  +<code>&lt;Location&gt;</code>.
   
   <P>The <CODE>Location</CODE> functionality is especially useful when
   combined with the <CODE><A
  @@ -1355,6 +1362,23 @@
       allow from .foo.com
       &lt;/Location&gt;
   </PRE>
  +
  +<p><strong>Apache 1.3 and above note about / (slash)</strong>:  The slash character has special
  +meaning depending on where in a URL it appears.  People may be used
  +to its behaviour in the filesystem where multiple adjacent slashes are
  +frequently collapsed to a single slash (i.e. <code>/home///foo</code>
  +is the same as <code>/home/foo</code>).  In URL-space this is not
  +necessarily true.  The <code>&lt;LocationMatch&gt;</code> directive
  +and the regex version of <code>&lt;Location&gt;</code> require you
  +to explicitly specify multiple slashes if that is your intention.
  +For example, <code>&lt;LocationMatch ^/abc&gt;</code> would match the
  +request URL <code>/abc</code> but not the request URL <code>//abc</code>.
  +The (non-regex) <code>&lt;Location&gt;</code> directive behaves
  +similarly when used for proxy requests.  But when (non-regex)
  +<code>&lt;Location&gt;</code> is used for non-proxy requests it will
  +implicitly match multiple slashes with a single slash.  For example,
  +if you specify <code>&lt;Location /abc/def&gt;</code> and the request
  +is to <code>/abc//def</code> then it will match.
   
   <P>
   <STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,