You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by br...@apache.org on 2013/11/21 18:42:42 UTC
svn commit: r1544259 - /subversion/trunk/subversion/mod_dav_svn/repos.c
Author: brane
Date: Thu Nov 21 17:42:41 2013
New Revision: 1544259
URL: http://svn.apache.org/r1544259
Log:
Return the correct error from mod_dav_svn if the repository path does not exist.
* subversion/mod_dav_svn/repos.c (get_resource): If the reason for not being
able to open a repositoy is ENOENT or ENOTDIR, then return a 404 status
instead of 500.
Modified:
subversion/trunk/subversion/mod_dav_svn/repos.c
Modified: subversion/trunk/subversion/mod_dav_svn/repos.c
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/mod_dav_svn/repos.c?rev=1544259&r1=1544258&r2=1544259&view=diff
==============================================================================
--- subversion/trunk/subversion/mod_dav_svn/repos.c (original)
+++ subversion/trunk/subversion/mod_dav_svn/repos.c Thu Nov 21 17:42:41 2013
@@ -2191,9 +2191,16 @@ get_resource(request_rec *r,
leak that path back to the client, because that would be
a security risk, but we do want to log the real error on
the server side. */
- return dav_svn__sanitize_error(serr, "Could not open the requested "
- "SVN filesystem",
- HTTP_INTERNAL_SERVER_ERROR, r);
+
+ apr_status_t cause = svn_error_root_cause(serr)->apr_err;
+ if (APR_STATUS_IS_ENOENT(cause) || APR_STATUS_IS_ENOTDIR(cause))
+ return dav_svn__sanitize_error(
+ serr, "Could not find the requested SVN filesystem",
+ HTTP_NOT_FOUND, r);
+ else
+ return dav_svn__sanitize_error(
+ serr, "Could not open the requested SVN filesystem",
+ HTTP_INTERNAL_SERVER_ERROR, r);
}
/* Cache the open repos for the next request on this connection */
Re: svn commit: r1544259 - /subversion/trunk/subversion/mod_dav_svn/repos.c
Posted by Ben Reser <be...@reser.org>.
On 11/21/13, 9:42 AM, brane@apache.org wrote:
> Author: brane
> Date: Thu Nov 21 17:42:41 2013
> New Revision: 1544259
>
> URL: http://svn.apache.org/r1544259
> Log:
> Return the correct error from mod_dav_svn if the repository path does not exist.
>
> * subversion/mod_dav_svn/repos.c (get_resource): If the reason for not being
> able to open a repositoy is ENOENT or ENOTDIR, then return a 404 status
> instead of 500.
This happens to have the side effect of making OPTIONS return a 404 when
running under SVNParentPath and the repo path doesn't exist. Technically I
don't think we should ever return an error to OPTIONS requests, but mod_dav_svn
doesn't provide us a way to say not to handle the OPTIONS request (and thus
fall back to httpd's default OPTIONS handler).
Not sure this is really a problem but thought I'd point out the possible HTTP
compliance issue here. I ran into this when I was doing some other work
lately, but decided I didn't care because this behavior already existed, just
noticed this commit today which introduced the behavior. Given that it's not
long standing behavior I'm not sure what we should do.
Re: svn commit: r1544259 - /subversion/trunk/subversion/mod_dav_svn/repos.c
Posted by Ben Reser <be...@reser.org>.
On 11/21/13, 9:42 AM, brane@apache.org wrote:
> Author: brane
> Date: Thu Nov 21 17:42:41 2013
> New Revision: 1544259
>
> URL: http://svn.apache.org/r1544259
> Log:
> Return the correct error from mod_dav_svn if the repository path does not exist.
>
> * subversion/mod_dav_svn/repos.c (get_resource): If the reason for not being
> able to open a repositoy is ENOENT or ENOTDIR, then return a 404 status
> instead of 500.
This happens to have the side effect of making OPTIONS return a 404 when
running under SVNParentPath and the repo path doesn't exist. Technically I
don't think we should ever return an error to OPTIONS requests, but mod_dav_svn
doesn't provide us a way to say not to handle the OPTIONS request (and thus
fall back to httpd's default OPTIONS handler).
Not sure this is really a problem but thought I'd point out the possible HTTP
compliance issue here. I ran into this when I was doing some other work
lately, but decided I didn't care because this behavior already existed, just
noticed this commit today which introduced the behavior. Given that it's not
long standing behavior I'm not sure what we should do.