On 01/07/2010 07:53 PM, C. Michael Pilato wrote:
> Kamesh Jayachandran wrote:
>
>>
>>> With all due respect, the proposed solution looks enormous compared to
>>> the
>>> size of the problem. Does the original problem exist in HTTPv2? At a
>>> minimum, could the ra_dav providers not annotate the PROPFIND as
>>> "dont-proxy-this" without even touching the RA (and higher) APIs?
>>>
>>>
>>>
>> I *think* neon still uses the old protocol i.e do not make POST requests
>> so suffers from original PROPFIND problem and hence need our fix.
>>
>> *serf* uses 'POST' request to get the baseline revision, 'POST' request
>> is proxied to MASTER so it does not suffer from this problem.
>>
> Yes, that's correct. Neon only grew partial HTTPv2 support, mostly for the
> read operations, but definitely *not* for commits. If switching to POST
> will fix this, then maybe that's the least invasive approach -- you (or
> someone) simply needs to get Neon doing HTTPv2 for commit stuffs.
>
> Another option (and I've not researched this, so it might be bogus) is to
> look into the target of that problematic PROPFIND. I mean, is the default
> VCC the only resource that can answer the query? If not, could perhaps some
> obviously-commit-related resource answer it (something in the activity,
> perhaps)? Do you happen to know exactly what is being asked for in that
> PROPFIND today?
>
>
Request look like this,
PROPFIND /svn2/demo/!svn/vcc/default HTTP/1.1^M
<?xml version="1.0" encoding="utf-8"?>
<propfind xmlns="DAV:">
<prop>
<checked-in xmlns="DAV:"/>
</prop></propfind>
With regards
Kamesh Jayachandran
Received on 2010-01-07 15:34:36 CET