phi...@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
