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

Re: Yet more DAV bugs

From: Lieven Govaerts <svnlgo_at_mobsol.be>
Date: Thu, 22 May 2008 22:54:53 +0200

epg_at_google.com wrote:
> Thanks for looking into this.
> Lieven Govaerts <svnlgo_at_mobsol.be> writes:
>> I've tested get_file_dir over ra_serf, and found that - unlike svnserve
>> - mod_dav_svn doesn't care if you're asking directory information
>> (PROPFIND allprop Depth:1) on a file. Which means that ra_serf doesn't
>> know anything was wrong.
> I can understand some people want to support things like this for
> compatibility for MICROS~1 Web folders or whatever. But we
> mustn't allow such side features to compromise svn itself.
>> Now we can correct this by adding an extra check to see of the directory
>> is really a directory. AFAIC the extra cost of the PROPFIND request to
>> the server is not worth it. Also, there's a nice workaround: if you
>> don't know if you're handling a file or a directory, use svn_ra_check_path.
> Extra round trips are no good, whether above or below the svn_ra
> hood.

> Right now, I'm issuing get_files with stupid code to try to figure out if it was a directory

I'm missing something here. You're asking an API to do something that
it's not meant for, expecting to get an error which clearly doesn't make
sense either? Why don't you use the correct API instead?

> and we're using neon; for
> serf, which proceeds to write some HTML error garbage into my
> file,

Well, the fact that ra_serf dumps the XML output is not correct either.
If that error comes from the server, I'd at least expect the same result
as you get for ra_neon now. Fixed in r31374.

> well, I just have to declare serf unsupported.

Sorry, no, can't have that :)


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-22 22:55:06 CEST

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.