svn commit: r1518347 - /subversion/site/publish/docs/release-notes/1.7.html

[br...@apache.org]

Author: breser
Date: Wed Aug 28 20:02:50 2013
New Revision: 1518347

URL: http://svn.apache.org/r1518347
Log:
* publish/docs/release-notes/1.7.html: Add a note about the change to
    mod_dav_svn no longer mapping requests to the local filesystem.

Modified:
    subversion/site/publish/docs/release-notes/1.7.html

Modified: subversion/site/publish/docs/release-notes/1.7.html
URL: http://svn.apache.org/viewvc/subversion/site/publish/docs/release-notes/1.7.html?rev=1518347&r1=1518346&r2=1518347&view=diff
==============================================================================
--- subversion/site/publish/docs/release-notes/1.7.html (original)
+++ subversion/site/publish/docs/release-notes/1.7.html Wed Aug 28 20:02:50 2013
@@ -1513,6 +1513,57 @@ single line:</p>
 
 </div>  <!-- mod_dontdothat-issue -->
 
+<div class="h3" id="mod_dav_svn-fsmap">
+<h3>mod_dav_svn Maps Requests to Local Filesystem
+  <a class="sectionlink" href="#mod_dav_svn-fsmap"
+    title="Link to this ssection">&para;</a>
+</h3>
+
+<p>Prior to Subversion 1.7.12 all previous versions of <tt>mod_dav_svn</tt>
+would allow Apache httpd to map requests handled by <tt>mod_dav_svn</tt> to the
+local file system. When this happened httpd would believe that it was serving a
+file or directory located at the path that comprises the URI path appended to
+the <tt>DocumentRoot</tt> of the server but ending at the first path component
+that does not actually exist on the local disk.  For example if your
+<tt>DocumentRoot</tt> was <tt>/var/www</tt> and you were accessing
+<tt>/svn/repo/README</tt> and <tt>/var/www/svn</tt> did not exist then
+httpd would believe it was serving <tt>/var/www/svn</tt>, but if
+<tt>/var/www/svn</tt> existed while <tt>/var/www/svn/repo</tt> did not then
+it would believe it was serving <tt>/var/www/svn/repo</tt>.  This had several
+undesired side effects.</p>
+
+<ul>
+  <li><tt>&lt;Directory&gt;</tt> blocks could match requests being served by
+    mod_dav_svn.  This would allow directives applied in these configuration
+    blocks (most notably access control directives) to be applied.
+  <li>When using Apache httpd 2.4.x and <tt>mod_dir</tt>, if a file from the
+    <tt>DirectoryIndex</tt> directive existed at the path Apache httpd believed
+    it was serving then the request would be rewritten to access that file,
+    which may or may not exist.  If the path was the <tt>SVNParentPath</tt>
+    then SVN would try to access a repository with the name of the
+    <tt>DirectoryIndex</tt> file that was found.
+  <li>When using the <tt>%f</tt> variable in your log directives you would log
+    the path constructed as described above.  This was confusing since it was
+    not the content that was actually served.
+</ul>
+
+<p>Starting with Subversion 1.7.12 the requests being served by
+<tt>mod_dav_svn</tt> will not be mapped to the local file system and when
+logging with the <tt>%f</tt> variable you will see a <tt>&quot;-&quot;</tt> logged.
+<tt>&lt;Directory&gt;</tt> blocks will no longer apply to such requests.
+
+<div class="notice">
+<p><span style="color: red"><b>WARNING:</b></span>Therefore, if you were
+using <tt>&lt;Directory&gt;</tt> blocks to restrict access to paths served
+by <tt>mod_dav_svn</tt> you will need to adjust your configuration.  Since
+the local filesystem path was not complete this never would have been very
+useful for path based authorization, but it could be abused for simple
+things like blocking an IP.  These directives must be moved inside the
+appropriate <tt>&lt;Location&gt;</tt> blocks.</p>
+</div>
+
+</div> <!-- mod_dav_svn-fsmap -->
+
 </div>  <!-- issues -->
 
 <div class="h2" id="distribution-changes">