Feature #1953
closedImprove DAV support to be able to handle git as a client
Description
After some fiddling, I was able to set up a DAV storage on lighttpd which git is able to write to. These are the steps necessary:
(0. The http requests will include "Expect: 100-continue", therefore lighttpd >= 1.4.21 with server.reject-expect-100-with-417 = "disable" is needed. Compile the server with --with-webdav-props --with-webdav-locks.)
1. Apply lighttpd-git-allprop.patch. This makes lighttpd reply with all known live properties on allprop PROPFIND requests.
2. Apply lighttpd-git-infinite-locks-regular-files.patch. Initially, lighttpd doesn't support LOCK requests with an infinite depth, but git only does this for existing regular files (or for new regular files) - this patch makes lighty allow this kind of locking requests and handles them like any other lock requests with a supported depth.
3. Apply lighttpd-git-append-slashes-on-directories.patch. When doing a PROPFIND with depth 1 (used for listing the content of a directory in git), git recurses doubly if subdirectories are listed without a slash at the end. Didn't find anything in the webdav RFC saying if this actually was mandated by the spec, but e.g. Apache does listings in this way. (This could of course also be fixed within git instead, by changing a string comparison to ignore the last slash.)
4. Apply lighttpd-git-supportedlock-property.patch. This makes lighttpd respond to the supportedlock property query.
Do these patches look ok to be merged into the official lighttpd branch? Patches 1, 2, 4 are quite straightforward improvements making it work slightly more like the spec. Patch 3 isn't as obviously a definitive step towards better spec compliance though, but shouldn't break anything either.
Files
Updated by mstorsjo over 15 years ago
I forgot to mention, even though this works, the operation is quite slow since most requests contain a "Expect: 100-continue" header, and libcurl has a one second timeout while waiting for a reply to that.
Updated by skelkingur almost 15 years ago
Is that patch going to be integrated / backported to 1.4.x? I'm having trouble with 1.4.25 and git http-push. After setting server.reject-expect-100-with-417 = "disable" the PROPFIND works. git http-push keeps aborting as the WebDAV locking mechanism isn't fully supported.
error: no DAV locking support on http://git.example.com/test.git/
fatal: git-http-push failed
I'd really appreciate to see that in the next release.
I just patched the current mod_webdav.c from lighttpd 1.4.25 and compiled it. This patch does not seem to work with the current version as the same error as mentioned above still occurs.
Updated by Tuxist about 13 years ago
please insert patches. i need this too for git.
Updated by stbuehler about 13 years ago
- Missing in 1.5.x set to No
you really should use git over ssh. search for gitosis / gitolite, probably solves all problems you have.
Updated by stbuehler over 8 years ago
- Related to Bug #2296: Saving file to webdav mapped drive fails added
Updated by gstrauss over 8 years ago
- Status changed from Patch Pending to Wontfix
The recommended solution is to run git-http-backend via CGI.
Instructions for how to configure lighttpd to run git-http-backend are included in the git-http-backend man page.
If there is a real need to get git working with lighttpd via mod_webdav, then please reopen this ticket. However, #1818 feature request for proper LOCK support in lighttpd mod_webdav is a prerequisite.
Updated by gstrauss over 8 years ago
Even though I marked this ticket as 'wontfix' because the superior solution is to run git-http-backend via CGI, I do plan to incorporate some of the patches since they do aim to improve things.
Updated by stbuehler over 8 years ago
- Related to Bug #2001: webdav: Allow propfind requests for specific properties added
Updated by gstrauss almost 8 years ago
- Status changed from Wontfix to Fixed
Marking this Fixed, as all the patches have been applied to address the issues raised here.
lighttpd 1.4.45 will support Expect: 100-continue in a more client-friendly way, so server.reject-expect-100-with-417 = "disable" will not longer be necessary (and that directive will be a no-op).
Also available in: Atom