Return current directory info on getDirectoryContents

[skjnldsv]

Hello!
Thanks for your awesome lib :)

I would like to not filter out the current directory while doing a getDirectoryContents to avoid an extra request to store the data, is this possible? !

webdav-client/source/interface/directoryContents.js

Lines 42 to 47 in 94f7053

	// Filter out the item pointing to the current directory (not needed)
	.filter(item => {
	let href = getSingleValue(getValueForKey("href", item));
	href = pathPosix.join(normalisePath(normaliseHREF(href)), "/");
	return href !== serverBase && href !== remoteTargetPath;
	})

Have a great day!

[perry-mitchell]

Hi! Currently no, as this wouldn't make sense in the vast majority of use cases. You could use a custom request to handle this yourself, though.

[skjnldsv]

Hi! Currently no, as this wouldn't make sense in the vast majority of use cases. You could use a custom request to handle this yourself, though.

wrong link? You meant this? https://github.com/perry-mitchell/webdav-client#custom-requests
Thanks for the tip :)

[perry-mitchell]

@skjnldsv Sorry! Random clipboard data.. Thanks.

If you come up with any ideas that you might want to explore here just let me know. Cheers :)

[skjnldsv]

hey @perry-mitchell :)

I'd kindly ask you to re-open.
This lib is manually removing data from the what the RFC require webdav to return.

A regular PROPFIND also returns the current collection. I think it does make sense to offer this, at least with a boolean option as this actually is part of the initial webdav specifications :)

<?xml version="1.0"?>
<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:oc="http://owncloud.org/ns" xmlns:nc="http://nextcloud.org/ns">
	<d:response>
		<d:href>/remote.php/dav/trashbin/admin/trash/</d:href>
		<d:propstat>
			<d:prop>
				<d:resourcetype>
					<d:collection/>
				</d:resourcetype>
			</d:prop>
			<d:status>HTTP/1.1 200 OK</d:status>
		</d:propstat>
	</d:response>
	<d:response>
		<d:href>/remote.php/dav/trashbin/admin/trash/1e255300-a6e9-4944-a275-c0cad2e05843.vcf.d1674135367</d:href>
		<d:propstat>
			<d:prop>
				<d:getlastmodified>Thu, 19 Jan 2023 13:36:07 GMT</d:getlastmodified>
				<d:getcontentlength>1266</d:getcontentlength>
				<d:resourcetype/>
				<d:getetag>1674135367</d:getetag>
				<d:getcontenttype>text/vcard</d:getcontenttype>
			</d:prop>
			<d:status>HTTP/1.1 200 OK</d:status>
		</d:propstat>
	</d:response>
</d:multistatus>

[skjnldsv]

https://www.rfc-editor.org/rfc/rfc4918#section-9.1.4

>>Request
 PROPFIND /container/ HTTP/1.1
 Host: www.example.com
 Content-Type: application/xml; charset="utf-8"
 Content-Length: xxxx
 <?xml version="1.0" encoding="utf-8" ?>
 <propfind xmlns="DAV:">
   <propname/>
 </propfind>

>>Response
 HTTP/1.1 207 Multi-Status
 Content-Type: application/xml; charset="utf-8"
 Content-Length: xxxx
 <?xml version="1.0" encoding="utf-8" ?>
 <multistatus xmlns="DAV:">
   <response>
     <href>http://www.example.com/container/</href>
     <propstat>
       <prop xmlns:R="http://ns.example.com/boxschema/">
         <R:bigbox/>
         <R:author/>
         <creationdate/>
         <displayname/>
         <resourcetype/>
         <supportedlock/>
       </prop>
       <status>HTTP/1.1 200 OK</status>
     </propstat>
   </response>
   <response>
     <href>http://www.example.com/container/front.html</href>
     <propstat>
       <prop xmlns:R="http://ns.example.com/boxschema/">
         <R:bigbox/>
         <creationdate/>
         <displayname/>
         <getcontentlength/>
         <getcontenttype/>
         <getetag/>
         <getlastmodified/>
         <resourcetype/>
         <supportedlock/>
       </prop>
       <status>HTTP/1.1 200 OK</status>
     </propstat>
   </response>
 </multistatus>

In this example, PROPFIND is invoked on the collection resource
http://www.example.com/container/, with a propfind XML element
containing the propname XML element, meaning the name of all
properties should be returned.  Since no Depth header is present, it
assumes its default value of "infinity", meaning the name of the
properties on the collection and all its descendants should be
returned.

Consistent with the previous example, resource
http://www.example.com/container/ has six properties defined on it:
bigbox and author in the "http://ns.example.com/boxschema/"
namespace, and creationdate, displayname, resourcetype, and
supportedlock in the "DAV:" namespace.

The resource http://www.example.com/container/index.html, a member of
the "container" collection, has nine properties defined on it, bigbox
in the "http://ns.example.com/boxschema/" namespace and creationdate,
displayname, getcontentlength, getcontenttype, getetag,
getlastmodified, resourcetype, and supportedlock in the "DAV:"
namespace.

This example also demonstrates the use of XML namespace scoping and
the default namespace.  Since the "xmlns" attribute does not contain
a prefix, the namespace applies by default to all enclosed elements.
Hence, all elements that do not explicitly state the namespace to
which they belong are members of the "DAV:" namespace.

[skjnldsv]

Despite the obvious use I would have for this, from a technical POV changing what the rfc specifications clearly define makes it proplematic I think :)

If I assume this library is a node interface to webdav, then reading the webdadv rfc and using the appropriate methods here should also allow me to get a feature parity experience :)

While I would myself make it the default for the sake of rfc and consistency, I also completely understand your argument above about fitting people's use cases.
So I think supporting this with a option.includeCollection or something equivalent would also make sense. 😉

[perry-mitchell]

Thanks for continuing to look into this. What format would you suppose the response be in if one was to specify that they'd want the current collection as well? Just the object structure for the current directory?

I'd accept a PR for that, yes. Default false of course.

Just to reiterate - despite the name of this library it is not this project's goal to achieve feature parity with any WebDAV RFC or spec. That being said I do agree with adding this option.

[skjnldsv]

Thanks for continuing to look into this. What format would you suppose the response be in if one was to specify that they'd want the current collection as well? Just the object structure for the current directory?

Yes, I think I would just keep the response as is, and let your library parse method do its magic :)
It would basically look like getDirectoryContents is merged with a stat on the collection I guess? 🤔

Just to reiterate - despite the name of this library it is not this project's goal to achieve feature parity with any WebDAV RFC or spec. That being said I do agree with adding this option.

I'll keep that in mind! :)
Thanks for the positive reply! Indeed, this library's name might be a bit too close to the service name 🙈

[skjnldsv]

#334 @perry-mitchell