Greg Stein <gstein@lyra.org> writes:
> For some properties, you may need *two* locations for enforcement. One in
> the client, but also one in the server.
>
> All but svn:mime-type are pure client properties. The server is completely
> ignorant about them; thus, the props only need client-side enforcement. I
> think you should also analyze what library uses them, which then states
> where the enforcement occurs.
>
> But you still have the question: if libsvn_wc enforces svn:executable to
> only be on files, should we also encode that in the FS so that somebody
> cannot "go straight to the FS, insert a 'bad' property, and monkey with the
> WC when it finally receives the property" ??
I think we needn't enforce them on the server, because it's not so bad
to accidentally get these properties on the wrong kind of target --
rather, it's just [probably] an indication that the user didn't do
what they meant to do. Hence the preventative but overcomeable check.
A WC that accidentally has a property on the wrong kind of target
won't behave badly; that property will just be ignored.
> Back to svn:mime-type... the server *does* use this, by returning it in the
> Content-Type header for a GET request (actually, it appears in other places,
> too). Thus, it is appropriate to have "deep" validation on it: both client
> and server side. Per Fitz's point, dirs might also have a mime type, but we
> should validate that it has the form "majortype/subtype"
So for mime-type, we validate the form of the value, instead of
validating target. Sounds good to me!
> My personal preference is to provide enforcement only on the client side,
> yet allow the client to deal gracefully with server-side-monkeyed
> properties (issue a warning). The mime type should be enforced by
> mod_dav_svn and libsvn_client (or libsvn_wc if the WC looks at it).
I'm not even sure the client should issue a warning in those cases
(then we'd have to have a way to turn the warning off, for those who
really did mean to do that, etc...).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 21 22:55:50 2002