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?
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-01-07 15:24:12 CET