Tue 31 Jan 2012 11:31:37 PM UTC, comment #13:
Hey Werner.
I'm not a WebDAV expert at all... but I asked a friend of the dCache developers (credits to Paul Millar) who gave me some answers:
------------------------------------------------------
The simple answer is read the corresponding RFCs: RFC 4918, RFC 2616 and maybe RFC 4437.
Here are some answers to the specific questions at the top of the above Savannah ticket:
> A Redirect in response to GET seems not too difficult;
> just repeat the request to 'Location'.
Correct; this should work fine and solves a number of issues for us.
> But this is WebDAV - where to send PUT?
We (dCache.org) would like clients to support redirect on PUT, too; however, this is likely to be more of an uphill struggle.
dCache current behaviour is to proxy/tunnel the incoming data to the corresponding pool node; so dCache will work "OK" with clients that don't support redirect for PUT.
The issue is that, although this is functional, it doesn't scale. If lots of clients are trying to write data then you will need lots of doors.
RFC 2616 defines behaviour if the server returns HTTP code 307 to a PUT request. The client should honour the redirect; however, as-is, this would involve sending the data twice: once to the door (only to receive a 307) and once to the pool.
> - will PROPFIND be redirected too.
dCache doesn't do this (so we don't care), but it is technically possible. RFC 4437 seems to go into this issue in some detail.
> - has davfs2 to remember a different server for every
> resource or should it just direct every request to the
> initial server and repeat it in case of a redirect?
This is basically just a question about caching. Read RFC 2616 for details, but the short answer is client may cache redirections for the duration specified by the server (in HTTP headers).
> (This might be expensive for PUT.)
Yes, but there's an extension / work-around / proposal to remove the additional cost for PUT.
-----------------------------------------------------------
So much for Paul's answers. I've opened a ticket at dCache.org, with respect to dafs2 / dCache-webdav interaction.
Unfortunately the ticket system there is not publicly visible, but you can add questions to it, by sending mail to -unavailable- with the subject being "#6991 WebDAV guru needed". I guess they will give you some friendly help, especially when it comes to interaction questions with dCache's WebDAV server.
My own "answers" perhaps:
- as Paul already said,.. if redirects would be supported for PUT, too, that would be great.
> has davfs2 to remember a different server for every
> resource or should it just direct every request to the
> initial server and repeat it in case of a redirect?
As Paul said, at most to the extent of what cahing allows... the storage system behind might have already moved the data to some other physical host.
So I guess (really just a guess) dCache would always return "0" for the caching time.
>And there are read-only repositories. How is the indendet
>use case here?
>Will davfs2 just be used to get a local copy, in which
>case plain HTTP/HTML might be the better solution.
I'm not sure how far davfs / FUSE use the kernels filesystem cache... but this could be one use case.
Though I haven't thought about the implications of filesystem caching... I mean somehow you'd have to update the status of cached files (whether they still exist, have been changed, etc.)
>Or is mapping into a local file system required, e.g.
>because applications want to access the resources through
>the file system interface?
This is IMHO definitely also a strong reason!
Cheers,
Chris
|