Ben Reser <ben@reser.org> writes:
> As far as this being DAV specific. I presume that DAV is where we got
> the whole concept of properties and our properties are designed around
> that specification. I don't see what's so bad about having some
> limitations on property names. So long as those limitations are spelled
> out. Which I think we've done a poor job of doing.
No, we didn't get the idea of properties from DAV. We knew we wanted
key/value pairs even before we'd heard of DAV. Now we are imposing
limitations on the keys, because of one (out of three) RA protocols.
> Well this was already done a long time ago. I could easily open up the
> available number of characters in property names by using a namespace
> hack. However, this is competely incompatable with our existing
> clients. Plus it's a total pain in the butt to try and negotiate this
> with clients. So if we're going to do this it's a 2.0 thing in my mind.
I'm not sure it has to wait until 2.0. We could add the feature
compatibly with a new "svn:quoted-propname:" prefix. (I'm being
verbose; obviously it doesn't have to be that long.)
Since Subversion owns the "svn:" namespace, we don't have to worry
about compatibility with older clients *or* servers. No one else is
creating "svn:" properties, and if they are, it's in violation of a
long-published standard.
With this enhancement, anytime someone sets a property whose name
contains special characters, we transform it into
"svn:quoted-propname:<quoted-str>" for transport. In the actual
working copy, and in the repository, it does not need the quoting,
because our storage formats there can handle the real names. However,
if an older repository happens to keep the quoting, that's okay! Old
clients will simply fail to unquote it; new clients will correctly
unquote it. No one will crash, and all information will be preserved
in one of two possible forms, until eventually everyone is upgraded.
I'm not saying this enhancement should delay 1.1 or even 1.2. I am
merely asking if anyone disagrees that the situation is a bug, and
secondarily asking if the above method seems like it would fix it.
It seems quite reasonable to me that people want "/" in property
names, just as they want ":". We've already had real-world examples
of both.
> But for now, we need to follow what we've got. The acceptance by the
> lower level layers of property names not accepted by the client layers
> is a bug IMHO.
Sure. While we have the bug, we have the bug, and we should deal
gracefully with it.
> But if you really want to talk about the more subtle issue... The more
> subtle issue is a lack of thought into what constitutes valid syntaxes
> for a variety of things. As a result we're not enforcing these syntaxes
> and as a result people get really strange behavior when they get outside
> of what people normally use.
>
> Pathnames and property names are good examples that we've already run
> into. There are a number of reasons why we should define these things
> clearly:
>
> * Helps people adopting the software know our limitations.
> * Lets anyone planning on implementing another RA layer or FS layer or
> anything else know what they have to support and don't have to support.
> * Helps us write better tests to look for bugs.
> * Allows people writing code to better take into account the
> consequences of their code. Some implementations of network and fs
> layers will by necessity apply special meaning to characters. They
> better make sure that they escape or handle such characters that are
> allowed to avoid potential security issues for their special meanings.
>
> We've also got issues like this in the svn protocol. Just how long is a
> valid string? There's absolutely no definition. So theoretically we
> have to allow any amount. Which ended up causing security implicatons
> for us.
>
> The length of what a property value is allowed to be played into this.
> It's not specified either. So once again we had to just stick our heads
> in the sand and support an unlimited amount.
>
> I don't think you can ever support every imaginable naming or length
> that a user might want. But we have to pick something and then follow
> it. If we want to be fairly unrestrictive then we need to say that so
> implementors know to expect unusual characters.
Good point.
I certainly agree that we should decide on a valid syntax for property
names (and values, for that matter), among other things. But the
limitations encouraged by DAV are far too narrow, and we shouldn't
settle for them unless we have absolutely no choice.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 22 00:37:44 2004