Malcolm Rowe wrote:
> On Wed, Mar 21, 2007 at 03:44:31PM -0000, cmpilato@tigris.org wrote:
>> http://subversion.tigris.org/issues/show_bug.cgi?id=2748
>>
>> +1. As I've stated in the past, mod_dav_svn is effectively user-facing, and
>> yes, should be in the business of validating input (and rejecting the invalid).
>
> In the past, there've been discussions about where validation should
> occur. Shouldn't this kind of validation occur in the repository or
> filesystem layers, or should the filesystem just treat a filename as a
> string of bytes?
The filesystem lives behind and API that demands UTF-8, Subversion-canonical
paths. Users of that API are expected to adhere to it. That lives behind a
repository API with the same rules and expectations. That lives behind
mod_dav_svn (in this flow). But mod_dav_svn is different. It isn't
accessed programmatically -- it's access over an network protocol that we
don't -- and don't want to -- control.
So I think we want parity with the client side in terms of where we check
for valid paths. "Userland" input is expected to be misshapen and crazy,
because it comes from users (not from programmers who know how to follow the
rules of an API). So the borders we guards are the ones between the users
and their entry point into our system.
In the command-line client case, we try to automagically massage user input
input a format our APIs can deal with. We could try the same for
mod_dav_svn, but I suspect it's largely impossible since there's no data
which comes along with malformed URLs to tell us how they are malformed like
we can get by checking the locale for command-line client input.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Wed Mar 21 17:13:48 2007