svnsync "207 Multi-Status" failure with http access method and property "svn:"

[Kylo Ginsberg]

Preparatory to setting up a proxy server, I'm trying to svnsync a
repository from 1.6.6 server to another 1.6.6 server (both x86_64
linux, one Fedora 7, one Fedora 12). Some user somehow managed to
create a property "svn:" on a file and the svnsync fails like so:

Transmitting file data .svnsync: At least one property change failed;
repository is unchanged
svnsync: PROPPATCH of
'/svn-proxy-sync/!svn/wrk/82bb957d-3816-45ed-a262-dadb63d80787/users/jwhiteman/python/cfg/CFG.xml':
207 Multi-Status (http://hood)

I'm able to reproduce (what I assume is) the same problem without svnsync:
1) create a repo, with both svn and http access methods
2) via svn access method create a file, set an "svn:" property, and
commit it, e.g.
svn co svn://snow/test test
cd test/
echo foo > foo.txt
svn add foo.txt
svn ps svn: asdf foo.txt
svn ci -m testing
3) now try to access it via http:
> svn pl http://snow/test/foo.txt
svn: PROPFIND of '/test/!svn/bc/1/foo.txt': 207 Multi-Status (http://snow)

So two questions here:
1) Is this a known issue? (I didn't see it in the bug db.) If not,
can I get a second nomination that this is a bug? (If someone can
point me in the right direction, and if this is likely to be a
somewhat surgical fix, I'd be happy to attempt a patch.)
2) Any recommendations on how to proceed? For the initial sync of
repos I can probably force the issue by svnsync'ing via the svn access
method, but I don't think this will work once I set up write-through
proxying.

Thanks!
Kylo

[Kylo Ginsberg]

Self-bump and post to dev list also. Posting 2 days before Christmas
seems to be a bad way to get a response ... ;>

[C. Michael Pilato]

Ben Collins-Sussman wrote:
> Is svnserve really allowing you to create a random svn: junk property?
> I was pretty sure that servers validated svn: properties -- only a
> scant few exist, and users aren't supposed to be able to invent them.
> My guess is that apache is throwing an error (207 mult-status probably
> contains a 5XX code inside it somewhere) when it fails validate the
> outgoing svn:asdf property, and then the svn client chokes on the
> error.

I'm pretty sure we do NOT have server validation of svn: property names. To
date, most of our svn: properties are for client functionality only, so we
would have been painting ourselves into a corner by having servers validate
those suckers (forcing folks to upgrade servers just to get
server-independent client functionality).

Also, Ben, you read Kylo's mail incorrectly. He didn't create an "svn:asdf"
property. He created an "svn:" property with value "asdf". So *my* guess
is that when mod_dav_svn is converting repository property names (such as
"svn:keywords") into PROPFIND response XML tags (such as "<S:keywords>"),
this "svn:" property is causing an essentially nameless tag ("<S:>") to be
generated and transmitted, which causes the client's XML parser to croak.

--
C. Michael Pilato <cmpi...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand

[Engebakken Geir]

We have experienced the "207 Multi-status" error in subversion when diffing to revisions of a file. A search for a solution, and posting to the user list did not help us, so we still live with the problem that only has appeared for some files. It might have something to do with a SCM conversion utility that we have used, but we don't know.

It seems to me that the 207 message is not an error message seen from Apache, rather an informative message, but that SVN interprets it as an error somehow. I would be glad to find out more about this ........

Sorry for not being able to help out more ....

Geir

[C. Michael Pilato]

Engebakken Geir wrote:
> It seems to me that the 207 message is not an error message seen from
> Apache, rather an informative message, but that SVN interprets it as an
> error somehow. I would be glad to find out more about this ........

"207 Multi-Status" isn't an error at all. It's a code from Apache that
means, "I've got multiple different pieces of status information to provide
to you -- see the response body for details."

In Subversion, those multiple bits of status generally correspond to
individual statii (heh) of property requests. Subversion says, "Apache,
please send me properties 'foo', 'bar', and 'baz' on file.txt." But what if
there's no 'bar' property on that file? Apache can't reply "200 OK",
because all is not well. It can't reply "404 Item Not Found", because some
of the items *were* found. So it replies "207 Multi-Status", and the body
of the response contains the property values and 200 statuses for the
requested properties that actually exist, plus 404 statuses for the
properties that *don't* exist.

[Engebakken Geir]

Right, but why doesn't the client handle this more "graciously", by examining the result and maybe point the user in a direction to find the cause of the "failure", instead of just spitting out "207 Multi-status"?

In our case we get this message diffing two revisions of a file, but we don’t know why it fails (although some time ago someone said something about cvs2svn not converting things correctly in all circumstances, leading to this error?).

Anyhow, the bottom line for me is that diffing these revisions still fails, and I don’t know why!


Geir

-----Original Message-----
From: C. Michael Pilato [mailto:cmpi...@collab.net]
Sent: 5. januar 2010 13:54
To: Engebakken Geir
Cc: Kylo Ginsberg; us...@subversion.apache.org; d...@subversion.apache.org
Subject: Re: svnsync "207 Multi-Status" failure with http access method and property "svn:"

[Engebakken Geir]

If someone is interested, this is what I found about cvs2svn problems generating this "207 Multi-status" return code.

http://old.nabble.com/bug-with---auto-props:-PROPFIND-pf...:-207-Multi-Status-td18510529.html



Geir

[C. Michael Pilato]

Sure. Ideally, the client would be able to say, "I had trouble parsing the
XML in the response, namely this bit here: <S:>asdf</S:>"

Wanna dive in and look into a patch?

[Ben Collins-Sussman]

Is svnserve really allowing you to create a random svn: junk property?
I was pretty sure that servers validated svn: properties -- only a
scant few exist, and users aren't supposed to be able to invent them.
My guess is that apache is throwing an error (207 mult-status probably
contains a 5XX code inside it somewhere) when it fails validate the
outgoing svn:asdf property, and then the svn client chokes on the
error.

[Kylo Ginsberg]

So one bug/enhancement here is to improve client reporting when it
encounters a 207.

But back to the root of my original problem: I can create a "svn:"
property via the svn access method without any errors which then
results in errors when accessed via the http access method. That
seems like a bug, yes? But is the problem that the svn access method
*allows* this bogus property, or that http chokes on it?

I'd be willing to look into a patch if someone more knowledgeable
agrees on what the bug is and can provide some pointers on where to
start.

Kylo

[Andy Levy]

On Tue, Jan 5, 2010 at 11:28, Kylo Ginsberg <ky...@kylo.net> wrote:
> So one bug/enhancement here is to improve client reporting when it
> encounters a 207.
>
> But back to the root of my original problem: I can create a "svn:"
> property via the svn access method without any errors which then
> results in errors when accessed via the http access method.  That
> seems like a bug, yes?  But is the problem that the svn access method
> *allows* this bogus property, or that http chokes on it?

Flip a coin. One could make either argument about the root of the
problem. The bigger question is, if you code to prevent the bogus
property from being set, what will happen when you access a repository
via HTTP which already had those bogus properties set? You've stopped
people from setting them in the future, which is fine - but you still
have to handle the scenario where someone accesses the ones that were
previously set.

[Daniel Shahaf]

C. Michael Pilato wrote on Tue, 5 Jan 2010 at 00:32 -0500:
> Ben Collins-Sussman wrote:
> > Is svnserve really allowing you to create a random svn: junk property?
> > I was pretty sure that servers validated svn: properties -- only a
> > scant few exist, and users aren't supposed to be able to invent them.
> > My guess is that apache is throwing an error (207 mult-status probably
> > contains a 5XX code inside it somewhere) when it fails validate the
> > outgoing svn:asdf property, and then the svn client chokes on the
> > error.
>
> I'm pretty sure we do NOT have server validation of svn: property names. To
> date, most of our svn: properties are for client functionality only, so we
> would have been painting ourselves into a corner by having servers validate
> those suckers (forcing folks to upgrade servers just to get
> server-independent client functionality).

The server validates that the properties *it knows about* (e.g., svn:date,
svn:log) have valid values. Last I checked, we don't check either for
"unknown propname" svn:* props or for svn:* props used as versioned props
instead of revprops (or vice versa).

[Daniel Shahaf]

Kylo Ginsberg wrote on Tue, 5 Jan 2010 at 08:28 -0800:
> So one bug/enhancement here is to improve client reporting when it
> encounters a 207.
>
> But back to the root of my original problem: I can create a "svn:"
> property via the svn access method without any errors which then
> results in errors when accessed via the http access method. That
> seems like a bug, yes? But is the problem that the svn access method
> *allows* this bogus property, or that http chokes on it?
>

The latter. As far as libsvn_ra is concerned, property names can be any
UTF-8 string (values can be any byte string).

> I'd be willing to look into a patch if someone more knowledgeable
> agrees on what the bug is and can provide some pointers on where to
> start.
>

I don't know mod_dav_svn at all, so I'll let someone else answer here.

[Engebakken Geir]

Now you sound exactly as my boss sounds when I propose a fix somewhere :)

Not sure where to dive for the moment, we are mere users of SVN at the time being, but if this error prevails we might have to dig deeper. Thanks for the help though, great job you guys do!

[Branko Čibej]

C. Michael Pilato wrote:
> Sure. Ideally, the client would be able to say, "I had trouble parsing the
> XML in the response, namely this bit here: <S:>asdf</S:>"
>
> Wanna dive in and look into a patch?
>

Actually .... the svn: in property names should never have been
interpreted as an XML namespace name in the DAV protocol mapping. Now we
have to live with that ...

-- Brane