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

Re: [Issue 1807] ra_dav doesn't permit properties to have colons in their names.

From: Ben Reser <ben_at_reser.org>
Date: 2004-04-13 03:09:11 CEST

On Mon, Apr 12, 2004 at 08:25:10PM -0000, cmpilato@tigris.org wrote:
> Does XML have a "&colon;" entity when we can use to trivially escape those
> colons that are part of the custom property name?

No it doesn't. Though you can define one or use the numerical entity.
But this still doesn't really get us anywhere. Entities are not parsed
in tag names which is how the property names are expressed.

Custom properties work like so:

<C:propertyname ..>

Whereas SVN properties work like so:
<S:executable ..> (note the lack of the leading svn:).

We have a very limited character set to work with because a tag must be
a XML Name as defined in the XML standard:
http://www.w3.org/TR/REC-xml/#sec-common-syn

Which basically means we accept normal letters, numbers, '.', '-', '_',
':', and some other characters for non-english languags.

The colon is a special situation because colons are reserved in XML for
namespaces.

That doesn't give us much to escape with without possibly running into
cases where our escapes run into what someone might legitimately want to
use as a property name.

So my suggestion would be a slight namespace hack. Right now we're
using C:propname. So I say we reserve all namespaces starting with P
for custom usage and make propnames like so:

Psvk:signature

I'm not using C here because a name with a leading colon would be
disallowed by that and we currently allow such names. However, this
will only allow a single colon to be used. Which I would guess would be
the most common use case. I don't see a way around this as we can only
have 0 or 1 colons in a tag name.

I don't believe we're using any namespaces that begin with P, but I
could be wrong so someone more knowledgeable about this should verify
that.

Another alternative could be to use CCsvk:signature The specifics don't
matter so much as long as it is unique, reservable (on our part) and
distinguisable from the existing custom namespace.

We'll need to make filter_props directly handle the new namespace or set
an xmlns that it understands. The latter will mean we'll need to set a
namespace up for each and every unique entry before : that occurs in the
properties we're returning. Which might be ugly.

The other problem will be how to do this within our compatability
gurantees. propget and proplist work for versioned properties. Because
the property is not sent to the server and we're not rejecting the XML
with two colons. Unversioned properties propget on a colon named
property doesn't work beause we're asking for a specific property and
the webserver is rejecting the XML.

If they universally didn't work with DAV, I'd say we could just punt on
the compatability here. But they do work in some cases. Possibly
cases that people are using.

One way to deal with this would be to send a header of some sort to the
server to specify the new formating for the coloned properties.

Pure DAV clients still wouldn't be able to deal with these properties,
but I don't think DAV would support properties with colons in the name
really anyway. Plus they're getting property names with our namespace
preceding them anyway, so I'm not sure how useful our properties are to
them now anyway. I'm guessing that true DAV compatability isn't really
possible till 2.0.0 anyway.

So this would be something that we could do on trunk and then put in
1.1.0.

Thoughts?

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 13 03:09:32 2004

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.