WebDAV list not implement correctly

[Xuanwo]

• request should be sent during next_page
• Should add support for recursive if service support

[bxb100]

other information:

Servers should treat a request without a Depth header as if a "Depth: infinity" header was included.¹

403 Forbidden - A server may reject PROPFIND requests on collections with depth header of "Infinity", in which case it should use this error with the precondition code 'propfind-finite-depth' inside the error body.²

jianguoyun doesn't support Depth:infinity, default behavior is Depth:1 and doesn't return 403

---

• with Depth:infinity

• with Depth:1

• without Depth

Footnotes

1. http://www.webdav.org/specs/rfc4918.html#rfc.section.9.1.p.2 ↩

2. http://www.webdav.org/specs/rfc4918.html#rfc.section.9.1.1.p.2 ↩

[Xuanwo]

Yes, I do be aware that jianguoyun doesn't closely adhere to the WebDAV specifications. Super sad.

The best approach is to set the current list implementation as the default and add support for recursive lists. Additionally, we should provide documentation for this feature and clearly state that Jianguoyun does not support it.

[bxb100]

sry for misleading you, I just want to point this is not a widely supported implementation(RFC uses should not must terminology¹)

Footnotes

1. https://datatracker.ietf.org/doc/html/rfc2119#:~:text=3.%20SHOULD%20%20%20This%20word%2C%20or%20the%20adjective%20%22RECOMMENDED%22%2C%20mean%20that%20there%0A%20%20%20may%20exist%20valid%20reasons%20in%20particular%20circumstances%20to%20ignore%20a%0A%20%20%20particular%20item%2C%20but%20the%20full%20implications%20must%20be%20understood%20and%0A%20%20%20carefully%20weighed%20before%20choosing%20a%20different%20course. ↩

[tonghuaroot]

I spent some time reproducing this against real WebDAV servers and wanted to
share what I found, in case it helps decide the direction.

Recursive list already works on every WebDAV backend today. OpenDAL's
always-on SimulateLayer performs a client-side Depth: 1 walk (via
FlatLister) whenever a service does not advertise native recursive list, so
list_with_recursive works on nginx, ownCloud, and Nextcloud right now. I
confirmed this with the behavior suite against the docker-compose fixtures the
CI uses: ownCloud, for example, passes all 6 recursive list tests via the
simulated walk.

Native Depth: infinity is not uniformly supported, so it cannot be enabled
globally. OpenDAL capabilities are static (set at build time), and the WebDAV
servers disagree on whether Depth: infinity is allowed:

• nginx (dgraziotin/nginx-webdav-nononsense, the default CI setup): rejects
  Depth: infinity with HTTP 403.
• ownCloud 10.16.0 (Sabre/dav): rejects it with HTTP 412
  Depth infinity not supported.
• Nextcloud: honors it and returns the full recursive tree.

Because the recursive behavior tests run unconditionally against nginx,
ownCloud, and Nextcloud, setting list_with_recursive: true on the WebDAV
backend turns the matrix red (ownCloud 6/6 fail with 412, nginx 5/6 fail with
403) while making recursive list strictly worse on the infinity-rejecting
servers (a hard error instead of working via emulation). So a single global
capability flip does not look mergeable as-is.

While reproducing this I did find one genuine, backend-independent bug in the
recursive-list path: the native-recursive arm of SimulateAccessor::simulate_list
did not apply the parent-list + PrefixLister handling that the other two arms
apply for a path without a trailing slash, so listing e.g. dir/file
recursively on a native Depth: infinity backend dropped the prefix-sibling
dir/file2. I've opened a small standalone PR (#7705) for that fix (with a
regression test); it is green on the full CI matrix and is a prerequisite for
any future native enablement, but it does not by itself close this issue.

I'm happy to follow up with whatever direction you prefer for native
enablement (for example gating the recursive behavior tests to
Depth: infinity-capable backends, or keeping the current simulated walk as
the default and documenting that native infinity is server-dependent). Wanted
to surface the evidence first rather than guess at the CI policy.

[erickguan]

@tonghuaroot Thanks for digging! We have services that has config knobs to allow users configure their operators. We could add a feature flag to toggle support for list_with_recursive. Or we set up a flag to test backend heuristically. As you know simulate will change service behaviors, so you might want to take that into account.

Nice to get this problem addressed!