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

Re: certain property names cause non-wf XML responses

From: Julian Reschke <julian.reschke_at_gmx.de>
Date: 2004-10-18 21:32:48 CEST

Ben Reser wrote:
> On Mon, Oct 18, 2004 at 05:29:25PM -0000, kfogel@tigris.org wrote:
>
>>Assign to self, mark as started.
>>
>>By the way, I'm focussing on a long-term solution for permitting
>>colons, since people already need to use those (e.g., "svk:",
>>"cvs2svn:") and we know our current solution is not completely stable.
>>I'm working on the detailed proposal right now. While it will be
>>general enough to allow any character in a property name, I'm not
>>proposing that we actually allow all those characters yet. We can
>>start by just encoding colons, while continuing to disallow all other
>>non-XML-namespace-safe characters. The point is to get a permissive
>>decoding mechanism deployed, so we have the option of unrestricting
>>the other stuff later.
>>
>>Detailed proposal coming soon.
>
>
> Karl,
>
> We've been down this road before. I'll be so bold to say that you're
> wasting your time and that I'm probably going to -1 (veto) any proposal
> you have. Here's why...
>
> First and foremost this problem is the greatest for non-svn client
> implementations (i.e. DAV clients). These clients may be using XML
> parsers that enforce the XML namespace recommendations. This is
> unfortunate but understandable.

No, that's sticking to the spec. WebDAV requires clients and servers to
use XMLNS-aware XML parsers. Right now, svn clients and servers break
the spec, resulting in svn-over-DAV to be unusable for spec-compliant
clients.

> Any method of fixing this requires encoding. Because property names are
> passed as XML elements there is no way to encode the data such that a
> valid XML parser will automatically decode it for us. This means that
> we must encode our data before generating the XML and then decode it in
> the client after the XML parser is done.

That is correct.

> Let's consider that we have 3 classes of clients we need to support with
> this change:
>
> * Old SVN clients that don't know about encoding of property names.
> * New SVN clients thta do know about encoding of property names.
> * DAV clients that know nothing about SVN.
>
> Currently, we have no way of separating a SVN client from a generic DAV
> client. In order to fix the DAV clients that dislike our XML we'd need
> to be sure to encode for them. However, if we encode properties for
> them we'd also be encoding for the old SVN clients that don't know
> anything about encoding of properties.

Correct.

> In the past you've said that would be okay, they'd just get a property
> name that is different. But this is a compatability breakage. If
> talking to a 1.2 SVN DAV server makes svk:foo show up as some other name
> then existing SVK clients will break due to not seeing their property
> names. This would force all SVK users to upgrade to newer versions of
> SVK (or use a newer version of the bindings that know about the
> encoding) because the server was upgraded.
>
> As a result you can't fix the encoding problem for the only people it is
> creating a problem for (a small minority at that), the DAV clients.
> Without breaking our compatability with old SVN clients (a much larger
> group).
>
> Given that very few people have run into this issue. I think we have
> much more important things to worry about than this. Until 2.0 I think
> our only course of action is to discourage people from using colons in
> property names. Once 2.0 comes along we can break client
> interoperability and start encoding property names as you suggest.

Well, that sounds like "giving up" and just stating that the
XML-over-HTTP protocol that svn uses is - after all - not WebDAV. That's
certainly a valid approach, but if a decision is made to go that path,
Subversion should really stop to advertise itself of doing WebDAV.

As you said, if compatibility to existing old clients is required for
eternity, there is no way to fix this -- unless it's possible to detect
those old clients using user-agent request header sniffing (is it?).

However, if there's really no way to avoid either breaking RFC2518
compliance or existing old clients, I'd *certainly* vote for the latter.

Just my 2 cents,

Julian R.

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 18 21:33:11 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.