Just sharing this email exchange with Ben and the rest of the
dev-list. The mails were the result of my application of Ben's patch
for cleaning up DAV's property namespaces, and the subsequent
debugging that was forced to occur once 'make check' was run. :-)
------[ CMPILATO -> JORTON ]--------------------------------------------------
Hey, Joe. I've found a little bug in libsvn_ra_dav's handling of the
PROPFIND response. Allow me to spam you with an example:
PROPFIND /repos/greek-repos/A/D/gamma HTTP/1.1
User-Agent: neon/0.21.3 SVN/0.14.0 (dev build)
Keep-Alive:
Connection: TE, Keep-Alive
TE: trailers
Depth: 0
Content-Length: 326
Content-Type: text/xml
Host: localhost
<?xml version="1.0" encoding="utf-8"?>
<propfind xmlns="DAV:"><prop>
<version-controlled-configuration xmlns="DAV:"/>
<baseline-relative-path xmlns="svn:"/>
<baseline-relative-path xmlns="http://subversion.tigris.org/xmlns/dav/"/>
<baseline-relative-path xmlns="svn:"/>
<resourcetype xmlns="DAV:"/>
</prop></propfind>
HTTP/1.1 207 Multi-Status
Date: Fri, 09 Aug 2002 13:55:39 GMT
Server: Apache/2.0.40-dev (Unix) DAV/2 SVN/0.14.0 (dev build)
Content-Length: 731
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:">
<D:response xmlns:lp1="DAV:" xmlns:lp2="svn:" xmlns:g0="http://subversion.tigris.org/xmlns/dav/">
<D:href>/repos/greek-repos/A/D/gamma</D:href>
<D:propstat>
<D:prop>
<lp1:version-controlled-configuration><D:href>/repos/greek-repos/!svn/vcc/default</D:href></lp1:version-controlled-configuration>
<lp2:baseline-relative-path>A/D/gamma</lp2:baseline-relative-path>
<lp2:baseline-relative-path>A/D/gamma</lp2:baseline-relative-path>
<lp1:resourcetype/>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<g0:baseline-relative-path/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>
</D:multistatus>
Now, libsvn_ra_dav/props.c uses a very basic XML handler to read this
response which essentially just pulls all the <D:prop> things out for
examination. This causes a bit of problem for this particular
response, though, because we aren't paying any attention to which of
the <D:propstat> regions were are in, and more specifically, to the
<D:status> code assigned to that <D:propstat>.
So, I started tinkering around with the code there to try to track
which propstat I was in, and what the status was, and I didn't get too
far into before it occured to me that a) this sucks, and b) you
probably have a general Multistatus handler. And you do.
Helloooooooo, ne_207.h! :-)
I'm a little unsure of how to make that mingle nicely with the
libsvn_ra_dav code. Do I just use ne_207_create() and friends on the
parser returned from ne_propfind_get_parser()?
I'm afraid I'm a touch intimidated by the neon interfaces and the lack
of useful comments in Greg Stein's code. :-) But I really would like
to have this fix finished before we roll a tarball this afternoon.
Thanks in advance for any help you can offer.
------[ JORTON-> CMPILATO ]--------------------------------------------------
> Hey, Joe. I've found a little bug in libsvn_ra_dav's handling of the
> PROPFIND response. Allow me to spam you with an example:
[...shnip...]
> Now, libsvn_ra_dav/props.c uses a very basic XML handler to read this
> response which essentially just pulls all the <D:prop> things out for
> examination. This causes a bit of problem for this particular
> response, though, because we aren't paying any attention to which of
> the <D:propstat> regions were are in, and more specifically, to the
> <D:status> code assigned to that <D:propstat>.
The ne_propfind_* code is already paying attention to all these things,
fortunately ;). If you want to find out the status for the
baseline-relative-path property, you need to call ne_propset_status() on
the property result set passing in the property name - there's a comment
in props.c which shows where this code is missing.
So, e.g. to find out the status of fetching the baseline-relative-path
property, you need something like this in process_results():
{
const ne_status *st = ne_propset_status(rset, &starting_props[1]);
if (st->class != 2)
/* failed to fetch this property successfully */
else
/* fetched property ok */
}
Hope that helps!
------[ CMPILATO -> JORTON ]--------------------------------------------------
> So, e.g. to find out the status of fetching the baseline-relative-path
> property, you need something like this in process_results():
>
> {
> const ne_status *st = ne_propset_status(rset, &starting_props[1]);
>
> if (st->class != 2)
> /* failed to fetch this property successfully */
> else
> /* fetched property ok */
>
> }
Actually, I gotsa question for you. Currently, process_results()
looks like:
static void process_results(void *userdata, const char *uri,
const ne_prop_result_set *rset)
{
/* prop_ctx_t *pc = userdata; */
svn_ra_dav_resource_t *r = ne_propset_private(rset);
/* Only call iterate() on the 200-status properties. */
(void) ne_propset_iterate(rset, add_to_hash, r);
}
So I put a breakpoint on ne_propset_iterate(), and sure enough, when I
hit the breakpoint after the PROPFIND that I sent in my first mail,
RSET->numpstats == 2, the first one with a status of 200, the second
404. However, ne_propset_iterate() never called the add_to_hash()
callback like I expected, because the RSET->pstats[x].numprops was 0
for both of the pstats.
I'm terribly sorry if I'm missing something obvious or annoying you,
but I'm genuinely baffled.
------[ JORTON-> CMPILATO ]--------------------------------------------------
Ah :( I see the problem, it's an issue with neon unfortunately.
The propset only contains references to the "flat" properties (ones
treated as simple text strings): the properties you're dealing with are
"complex" properties for which ra_dav is parsing the XML. As neon never
"sees" the XML elements of these properties, it can't add them to the
propset, so there is no record of the mapping between each complex
property and the particular propstat it came in.
I'll have a ponder on how to fix this: no simple workarounds at the mo,
sorry.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 9 23:30:54 2002