[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

mod_dav_svn errors for POST and other requests

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Tue, 16 Apr 2013 12:40:06 +0100

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
Received on 2013-04-16 13:40:44 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.