Re: platform http ibrary

[Maciej Stachowiak <mjs noisehavoc org>]

On 27Nov2001 03:29PM (-0800), Greg Stein wrote:
> 
> PROPFIND support can be configured on a per-directory basis. For example, I
> use the following Apache config block all the time:
> 
> <Location /dav>
>   DAV On
> </Location>
> 
> Of course, that path can be anything, and it enables WebDAV support for just
> that one location (and children). This per-dir feature is pretty much the
> same for all DAV servers.

So we can't really cache per-server, which is unlikely to totally
solve Daniel's problem.
 
> I would recommend sending an OPTIONS request to the target location when you
> first connect to the server (you *are* using persistent connections, right?
> :-). In the OPTIONS result, will be the DAV: header, indicating WebDAV
> support on the server. If the header is not present, then it does not have
> DAV support, and you don't want to bother sending PROPFINDs.

We have found that many servers do not correctly support
OPTIONS. Also, when OPTION says DAV is off, PROPFIND is likely to
return an error, which is probably not any more expensive for the
non-DAV case. But OPTIONS + PROPFIND is at least a bit more expensive
than just PROPFIND in the DAV case. So I don't really see what OPTIONS
buys you.
 
> If you're using persistent connections, then caching it for the life of the
> connection should be quite sufficient (the OPTIONS request is a very small
> overhead).
> 
> If you aren't using persistent connections, then I would suggest caching it
> for the lifetime of the application (or a GNOME session suspend/resume
> event). But your larger priority (IMO :-) would be to add persistence.

We'd like to have persistent connections but I think it may be wiser
to switch to using an external http library, since this would be a
significant rewrite in either case.
 
> In general, I would think that if the directory has DAV support, then it
> will probably always have DAV support. So you could record that fact and
> just keep sending PROPFIND. And the failure mode is pretty easy: the first
> time your PROPFIND returns 405 (Method Not Allowed) or 501 (Not
> Implemented), then you mark that directory as "not DAV-enabled". Detecting a
> transition from non-DAV to DAV is a bit harder since you want to ask "how
> often should I probe?" I'd recommend the caching guidelines above. 

Essentially, then, it's only worth marking non-DAV locations as such,
and then only temporarily.

> In Nautilus, you could also do a probe if somebody manually attempts
> to switch a view from HTML-rendering (i.e. standard web browsing) to
> a DAV view.

If a location doesn't support DAV, the filesystem-like views will not
be available as options in the UI, so this is not possible.

> p.s. and I'd also note that I'm saddened that gnome-vfs reimplemented so
> much HTTP/DAV functionality that was already in Neon (which I pointed people
> at last year or so). So it goes... :-)

We haven't added that much http or DAV functionality since then. I
think a good long-term strategy for gnome-vfs would be to use a
separate library, such as Neon or libsoup, for http handling; but it
would be a fair amount of work to do the switch and get the results
rock solid. Patches would gladly be considered; at this point there
aren't enough people actively working on gnome-vfs to add cutting edge
features to the http code.


Regards,

Maciej