"Peter N. Lundblad" <peter@famlundblad.se> writes:
> I think this is a classical example of "fixing symptoms". Note that I
> already did the work in svnserve to canonicalize every (AFAICT) path
> coming from the net. I actually don't see the problem with that approach.
> OK, it might be more "academically correct" to check if paths are
> canonical instead of just canonicalize them. In practice, if something
> depends on a path being truly canonical, we still have possible crashes.
Hey, this isn't "fixing symptoms".
What we have here is a question of whether a protocol should be strict
or tolerant. The JavaSVN client was sending non-canonical paths to
the server. If our approach is to require a certain style of paths in
that protocol, then rejecting non-conformant paths isn't "fixing
symptoms", it's "enforcing protocol", a perfectly normal practice.
Now, we may decide, as per your svnserve observations, that we don't
*want* to be so strict here, and that it's better to canonicalize the
incoming paths, i.e, be tolerant. Both approaches have their
advantanges/disadvantages; neither is an example of "fixing symptoms".
(Your point about is_canonical not being smart enough is useful, but
it's unrelated to your larger point. That's just a code bug, not a
flaw in the overall plan. I assume that where you wrote "we still
have possible crashes", you were referring to that implementation
bug.)
> Instead of duplicating svn_path_canonicalize in is_canonical, we could
> just be a little more permissive to clients.
>
> Also, I didn't see any objection to the svnserve changes when I made them.
> It was even backported to 1.1.x.
Thanks for pointing it out -- I think Mike just didn't remember it
(neither did I, when he and I discussed the mod_dav_svn change).
Technically, the two protocols do not have to behave the same way.
One could be strict, the other permissive. But consistency would be
nice.
Does anyone else have thoughts about whether the server should demand
that the client speak to it in canonical paths always?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jan 15 18:56:24 2005