Can't see directories!

[Dan G]

Nice project by the way, thanks! I have this working with a remote apache+mod_dav server. Working fine, except I can't see the directories on the remote server displayed in the JS client.
For example, I see the following in the response from the server (there's a directory called "random_directory" in the /webdav root) - but no icon is displayed accordingly.

<D:href>/webdav/random_directory/</D:href>
<D:propstat>
<D:prop>
<lp1:resourcetype><D:collection/></lp1:resourcetype>
<lp1:creationdate>2016-06-01T11:56:46Z</lp1:creationdate>
<lp1:getlastmodified>Tue, 31 May 2016 22:23:24 GMT</lp1:getlastmodified>
<lp1:getetag>"1000-5342ad2417328"</lp1:getetag>
<D:supportedlock>
<D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
<D:lockentry>
<D:lockscope><D:shared/></D:lockscope>
<D:locktype><D:write/></D:locktype>
</D:lockentry>
</D:supportedlock>
<D:lockdiscovery/>
<D:getcontenttype>httpd/unix-directory</D:getcontenttype>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response xmlns:lp1="DAV:" xmlns:lp2="http://apache.org/dav/props/">

Do you have any clue why directories would not be displaying?

By the way, I managed to get over the CORS problems by putting this in the apache VirtualHost config:

Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Max-Age "1000"
#Header always set Access-Control-Allow-Headers "X-Requested-With, Content-Type, Origin, Authorization, Accept, Client-Security-Token, Accept-Encoding, Depth"
Header always set Access-Control-Allow-Headers "Authorization, Content-Type, Depth"
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT, PROPFIND"

RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]

[Kysic]

Hi,
I think that the problem is the leading slash after the directory name in "<D:href>/webdav/random_directory/</D:href>".
I think it was not present with my webdav server and it probably produces a bug because of the line :
var filename = decodeURI(fileHref.replace(/^.*\//, ''));
in extractDirContent(webdavResponse) function in webdavLayer.js file.

You can activate debug log (in browser console) by changing the "debug = false" to "debug = true" in the file webdavLayer.js and thus you will see how the server response is interpreted (that is too say if the directory is present in "dirContent.dirList" at the end of the method extractDirContent).

Then try to replace the line I previously quote by something like :
var filename = decodeURI(fileHref.replace(/^.*\/([^\/]+)\/*$/, '$1'));

[Dan G]

Hi, thanks for the quick response and tips.
I substituted that line and now directories are appearing - which is great.
However I think the regexp needs some tweaking because now the file and directories appear with the davroot prepended to the file/dir-name, ie

• /webdav/random_directory/
• /webdav/file1
• /webdav/file2
  ....
  Which obviously causes 404s on any request attempts to those files/dirs, as they are going to HOST/webdav//webdav/random_directory

PROPFIND  XHR  http://HOST:8080/webdav//webdav/random_directory//

I will have a look to see if I can update that regexp accordingly.

By the way, I haven't noticed any download functionality anywhere yet. Is that because you only needed upload? In which case, I will extend it to include download....

[Kysic]

Maybe you are using the first version of the regexp before I edit my message.
But even with the last version, you'll have a problem : in webdav response on the content of a directory, the directory it self is one of the entries.
With my webdav server, it's the only entry which ended with a "/" so it was working. But as it's not the case for you, a new filter has to be added to avoid the a directory to appear in itself.
I'll give it a look to correct it, maybe tomorrow.

For download, yes there is no "force dowload" functionality.
When you clic on a file, you will have the default behaviour of your browser for this kind of file.
If it's an archive by example, it should start a download, whereas if's a pdf or mp3 it may open in a new tab and you will have to ask your browser to save it somewhere.
Don't hesitate to extend it.

[Dan G]

Thanks for the update. Yes, I can confirm the directory "duplication" behaviour that you predicted. I'll await your correction....
Regarding the download behaviour - I'll take a further look to decide exactly what my application requires. Thanks again.

[Kysic]

I push a correction. Tell me if it works for you, and thanks for the feedback.

[Dan G]

Working nicely!
Great stuff, thanks Kysic...

[Dan G]

Closing the issue as it's definitely resolved