On Fri, 2003-01-03 at 18:01, Ben Collins-Sussman wrote:
> And as Greg Stein mentioned in the issue, this is correct. 405 means
> that there's no dav resource at that location (i.e. no repository).
> 404 means you're looking in a dav-y area, but the resource dosen't
> exist.
> Still, I guess it would be nice to throw *descriptive* error strings
> to the user, which is what you're trying to do. :-)
Yes - I agree that the return code from the server shouldn't be changed,
but merely the presentation of the error shown to the user.
Should the user actually see any of the HTTP error codes, or should all
errors be "translated" into something more descriptive?
> anything. Why not just wrap the error in the infinite-loop-break-out
> routine?
>
> > svn_path_remove_component(path_s);
> > if (path_s->len == len)
> > /* whoa, infinite loop, get out. */
> > return err;
> instead of 'return err', how about
> return svn_error_quick_wrap (err, "The path was not part of repository")
I tried this earlier today. It seems to work as expected. The output
when trying to do a checkout from an URL that isn't a DAV resource is
(there's no repository at /svn):
% svn co http://localhost:8000/svn/nothere
subversion/libsvn_ra_dav/props.c:540: (apr_err=175002)
svn: RA layer request failed
svn: The path was not part of repository
subversion/libsvn_ra_dav/util.c:81: (apr_err=175002)
svn: PROPFIND of /: 405 Method Not Allowed
I also tried this in place of "return err;"
return svn_error_createf(SVN_ERR_RA_ILLEGAL_URL, NULL,
"The path %s is not part of a repository",
parsed_url.path);
This results in the following output:
% svn co http://localhost:8000/svn/nothere
subversion/libsvn_ra_dav/props.c:539: (apr_err=170000)
svn: Bad URL passed to RA layer
svn: The path /svn/nothere is not part of a repository
Personally I think the second output is more descriptive. Both seem to
work fine and passes a "make check".
Should I make a small patch out of one of these changes?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jan 5 01:47:13 2003