Bug #266

WebDAV sub-folders not visible

Added by Anonymous almost 10 years ago. Updated about 7 years ago.

Status:FixedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:mod_webdav
Target version:-
Missing in 1.5.x:

Description

I'm using the mod_webdav plugin to 1.4.3. I have found that sub-folders which are visible from the server's filesystem do not show up in the webdav-mapped folder when I browse to it from a client. The relevant portion of my lighttpd.conf is here:


    $HTTP["url"] =~ "^/webdav($|/)" {
        webdav.activate = "enable" 
    }

    auth.backend            = "htpasswd" 
    auth.backend.htpasswd.userfile = "/usr/local/etc/htpasswd/passwd" 
    auth.require            = (
                                "/webdav/" =>
                                (
                                  "method"   => "basic",
                                  "realm"    => "WebDAV access",
                                  "require"  => "user=nick" 
                                ),
                              )

-- Nick Triantos

uri_escape.diff Magnifier - patch to fix bug #266 -- iclaymore (2.65 KB) Anonymous, 2005-11-05 15:28

Associated revisions

Revision 822
Added by jan almost 10 years ago

simplified buffer-encoding functions into one function
- all of them do some kind of string-to-hex conversion
(html, rel-uri, hex)
- add a rel-uri encoding next to the old rel-uri-part one
- fixes #266

History

#1 Updated by jan almost 10 years ago

  • Status changed from New to Assigned

#2 Updated by Anonymous almost 10 years ago

I have a similar problem (not sure if it is the same). When I browse the webdav server from windows xp some, seemingly random folders don't show up, while others do. When i browse from linux with cadaver all folders show up, but when i try to ls in the folders that didn't show up in windows xp I get the following error from cadaver: "XML parse error at line 771: xmlParseEntityRef: no name ."

-- jonlst

#3 Updated by Anonymous almost 10 years ago

Hi,

Characters must be URI-escaped and XML-escaped before they are put into DAV:href element of a XML document (e.g. a PROPFIND response). But in mod_webdav, they are not:


#!c
         buffer_append_string(b,"<D:href>");
         buffer_append_string_buffer(b, con->uri.scheme);
         buffer_append_string(b,"://");
         buffer_append_string_buffer(b, con->uri.authority);
         buffer_append_string_buffer(b, con->uri.path);
         buffer_append_string(b,"</D:href>\n");

Here's a thread discussing character escaping in Apache's mod_dav:
http://mailman.lyra.org/pipermail/dav-dev/2003-June/004761.html

You can see how Apache mod_dav does it by downloading its source and check mod_dav.c -> dav_send_multistatus() -> dav_xml_escape_uri():


#!c
         ap_rputs(DEBUG_CR "<D:href>", r);
         ap_rputs(dav_xml_escape_uri(r->pool, first->href), r);
         ap_rputs("</D:href>" DEBUG_CR, r); 

And, for your convenience, here's mod_dav's source:
http://www.webdav.org/mod_dav/mod_dav-1.0.3-1.3.6.tar.gz

-- iclaymore

#4 Updated by Anonymous almost 10 years ago

My previous patch fixed the bug by encoding some characters, but I'm not sure whether the list of characters encoded is complete or not.

http://trac.lighttpd.net/trac/attachment/ticket/266/uri_escape.diff

buffer_append_string_uri_encoded() is the same as buffer.c::buffer_append_string_url_encoded(), except that '/' is not encoded.

I've tested it a bit. Filenames with spaces inside can now be displayed correctly at client side (OS X 10.4.3).

-- iclaymore

#5 Updated by jan almost 10 years ago

  • Status changed from Assigned to Fixed
  • Resolution set to fixed

I cleaned up the code in buffer.c and added encoding like you described in changeset r822.

#6 Updated by Anonymous almost 10 years ago

Thank you.

-- iclaymore

#7 Updated by Anonymous about 7 years ago

  • Status changed from Fixed to Need Feedback
  • Resolution deleted (fixed)

This fix is incomplete. eg/ie the dav module does not %-encode '[' or ']'. This is not in compliance with weth RFC 3986. It means for example, that any webdav client using the neon library (eg davfs2) fails to see sub-folders with [ or ] in them.

-- tj.trevelyan

#8 Updated by stbuehler about 7 years ago

  • Status changed from Need Feedback to Fixed
  • Resolution set to fixed

Fixed in r2272.

Also available in: Atom