feat(services/webdav): Add user defined metadata support

[userzhy]

Which issue does this PR close?

Part of #4842.

Rationale for this change

This PR adds user-defined metadata support for the WebDAV service as part of the tracking issue #4842.

WebDAV protocol supports custom properties through the PROPPATCH method (RFC4918), which allows us to store user-defined metadata as DAV dead properties.

What changes are included in this PR?

• Add enable_user_metadata configuration option (default: false)
• Add enable_user_metadata() builder method
• Add OpenDAL custom namespace constants for storing user metadata as DAV properties
• Implement webdav_proppatch() method to set user metadata using RFC4918 PROPPATCH
• Implement build_proppatch_request() to generate XML request body
• Implement parse_user_metadata_from_xml() to extract user metadata from PROPFIND responses
• Update webdav_stat_rooted_abs_path() to parse and return user metadata
• Update WebdavWriter::write_once() to set user metadata via PROPPATCH after file upload
• Add unit tests for new functionality

User metadata is stored as dead properties in the OpenDAL namespace (od:) on WebDAV servers.

Note: This feature is disabled by default because not all WebDAV servers support PROPPATCH (e.g., nginx's basic WebDAV module doesn't). Users need to explicitly enable it via enable_user_metadata(true) if their server supports it (e.g., Apache mod_dav, Nextcloud, ownCloud).

Are there any user-facing changes?

Yes. Users can now use write_with_user_metadata when writing files to WebDAV storage (if enabled), and retrieve user metadata when calling stat().

Example usage:

let op = Operator::new(Webdav::default()
    .endpoint("[https://webdav.example.com](https://webdav.example.com)")
    .enable_user_metadata(true))?
    .finish();

AI Usage Statement

This PR was developed with assistance from GitHub Copilot (Claude Opus 4.5).

[Xuanwo]

Great work!

Could you also update our behavior test configuration and enable the metadata feature for supported services? Here's the link: https://github.com/apache/opendal/tree/main/.github/services/webdav.

Thank you in advance!

[userzhy]

@Xuanwo Thanks for the suggestion! I did try enabling it for Nextcloud and ownCloud, but ran into an issue.

The PROPPATCH part works fine - they accept our custom properties. But when reading back via PROPFIND with allprop, Nextcloud doesn't return custom namespace properties in the response. So the test fails at the verification step.

This seems to be a limitation of how Nextcloud implements allprop (RFC4918 does say servers may not return all dead properties). We'd need to explicitly request each property by name in PROPFIND, but that requires knowing what keys the user set beforehand.

For now I've kept the feature available but disabled the test for these servers. Let me know if you'd like me to look into a workaround, or if we should just document this as a known limitation.

[Xuanwo]

User metadata is stored as dead properties in the OpenDAL namespace (od:) on WebDAV servers.

I'm not sure if having our own namespace is the best approach. OpenDAL should ideally be capable of retrieving any user metadata. Do you think it would be a good idea to let users specify the namespace and namespace tag they prefer to use?

[Xuanwo]

Looks great, the only thing left here is enable the behavior tests.

[Xuanwo]

Seems we are parsing xml here. Can we use quick-xml instead?

[Xuanwo]

The same.

[userzhy]

@Xuanwo I've implemented the configurable namespace feature you suggested (user_metadata_prefix and user_metadata_uri options). Users can now specify their preferred namespace.

However, the behavior tests still can't be enabled for our current WebDAV test servers:

• nginx: Doesn't support PROPPATCH at all.
• Nextcloud/ownCloud: Accepts PROPPATCH writes, but doesn't return custom namespace properties in allprop responses (RFC4918 allows servers to omit dead properties from allprop).

The issue is that stat() uses <allprop/> since we don't know which property keys the user has set. To retrieve specific dead properties, we'd need to explicitly name them in the PROPFIND request - but that requires knowing the keys beforehand.

[Xuanwo]

The issue is that stat() uses <allprop/> since we don't know which property keys the user has set. To retrieve specific dead properties, we'd need to explicitly name them in the PROPFIND request - but that requires knowing the keys beforehand.

That's sad. Even if users set their own metadata, we still cannot provide it back to them in a meaningful way.

I'm fine with merging this PR as it is because the work here is excellent. However, I would like to know if you have interest to explore further into how Nextcloud implements file metadata listing. For example, they provide APIs such as:

./occ metadata:get 1742
{
    "my-first-meta": {
        "value": "yes",
        "type": "string",
        "indexed": false
    },
    "my-second-meta": {
        "value": 1234,
        "type": "int",
        "indexed": true
    }
}

[userzhy]

Thanks! I did some research on this.

Nextcloud 28+ has a dedicated metadata system using nc:metadata-* properties (e.g., nc:metadata-gps). This is the WebDAV equivalent of ./occ metadata:get. However, it still requires knowing property names upfront for PROPFIND — the allprop limitation remains.

I'm interested in exploring this further!