mod_dav_svn errors for POST and other requests

philip_at_apache.org writes:

> Author: philip
> Date: Tue Apr 16 10:12:51 2013
> New Revision: 1468347
>
> URL: http://svn.apache.org/r1468347
> Log:
> Make mod_dav_svn's handling of POST errors more like mod_dav's
> handling of errors for other requests. This makes MKACTIVITY
> and POST return the same underlying errors to the client.
>
> * subversion/mod_dav_svn/repos.c
> (handle_err): New, based on mod_dav's dav_handle_err.
> (dav_svn__method_post): Call handle_err.

For both the v1 and v2 protocols a MERGE that fails, due to permissions
say, returns a client error such as:

  $ svn -mm mkdir http://localhost:8888/obj/repo/A
  svn: E000013: Can't move '/home/pm/sw/subversion/obj/repo/db/txn-protorevs/2-b.rev' to '/home/pm/sw/subversion/obj/repo/db/revs/0/3': Permission denied

A v1 MKACTIVTY that fails returns a similar error:

  $ svn -mm mkdir http://localhost:8888/obj/repo/A
  svn: E000013: Can't create directory '/home/pm/sw/subversion/obj/repo/db/transactions/2-c.txn': Permission denied

and now POST returns the same error as MKACTIVTY. Before r1468347 POST
was returning:

  $ svn -mm mkdir http://localhost:8888/obj/repo/A
  svn: E000013: could not begin a transaction

So the error handling is now consistent across all requests which is
good. Unless it is consistently bad? Should mod_dav_svn be sanitising
the error to remove the system path? How would that be implemented?

Perhaps mod_dav_svn should only return a low level error is a very few
carefully controlled circumstances and shoul usually return the more
generic "could not begin a transaction" generated inside mod_dav_svn.

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download