[Bug]: WebDAV accepts fragment-bearing request targets for destructive methods

[AptS-1547]

What happened?

The pinned Litmus 0.13 basic suite introduced for #421 reports that AsterDrive performs a destructive WebDAV mutation when the raw request target contains a URI fragment.

In delete_fragment, Litmus sends a fragment-bearing DELETE request target. AsterDrive resolves it to the collection resource and removes that resource. URI fragments are not part of the HTTP request-target sent to an origin server, so accepting such a raw target for mutation creates ambiguous and unsafe path semantics.

Parent roadmap: #421

Steps to reproduce

1. Create a WebDAV collection.
2. Send a raw DELETE request whose request-target appends #fragment to that collection URI.
3. Query the original collection URI.
4. Alternatively, run pinned Litmus 0.13 group basic and inspect delete_fragment.

Expected behavior

• Fragment-bearing HTTP/WebDAV request targets are rejected before path resolution, preferably with 400 Bad Request.
• The underlying resource remains unchanged.
• The validation is shared by destructive WebDAV methods rather than patched only in DELETE.
• Regression tests cover DELETE, MKCOL, PUT, COPY, MOVE, and encoded # path segments so a legitimate %23 filename remains distinct from a raw fragment delimiter.
• Litmus 0.13 no longer emits the unsafe delete_fragment warning.

Actual behavior

Litmus reports:

WARNING: DELETE removed collection resource with Request-URI including fragment; unsafe

The collection is deleted successfully.

AsterDrive version

v0.4.0-rc.2 / current develop at 8584c3cf

Installation method

Built from source

Database backend

SQLite

Storage backend involved

WebDAV client path

Environment

• OS / distro: isolated integration-test server; Litmus client runs from pinned Ubuntu 24.04 tooling
• Browser or WebDAV client: Litmus 0.13 basic
• Reverse proxy: none
• Deployment notes: local filesystem-backed test policy

Error messages / logs

basic: delete_fragment passed with 1 protocol warning

Relevant configuration

# Default WebDAV test configuration.

Checklist

• I have searched existing issues for duplicates
• I have checked the documentation and FAQ
• I have removed secrets and private credentials from this report

[AptS-1547]

Risk reassessment: URI fragments and common WebDAV clients

Further investigation shows that this is a real parser-boundary bug with potentially destructive impact when triggered, but its likelihood under AsterDrive's current deployment and user model is low. The issue priority is therefore being reduced from High to Low, while keeping it open as a dependency-boundary bug.

RFC behavior

A URI fragment is handled by the user agent and is separated before the URI is dereferenced:

• RFC 3986 §3.5 defines fragments as client-side, indirect identification data.
• RFC 9110 §7.1 defines the HTTP target URI with the fragment component excluded.
• WebDAV's Destination header uses Simple-ref; its grammar contains an absolute URI or absolute path with an optional query, but no fragment component. See RFC 4918 §8.3 and RFC 4918 §10.3.

For a real filename containing #, a conforming client sends %23. A raw #fragment in the HTTP request-target is malformed/adversarial input rather than the normal representation of such a filename.

Common client behavior

The clients checked use the expected behavior:

• curl: a normal URL ending in #fragment sends only the portion before #; a filename containing # must be supplied as %23. curl can send an arbitrary raw target only through explicit low-level controls such as --request-target.
• rclone WebDAV: paths go through URLPathEscapeAll, which escapes every character except RFC 3986 unreserved characters and /. Its WebDAV COPY/MOVE implementation builds Destination from that escaped path, so # is emitted as %23.
• Nextcloud Desktop: WebDAV MOVE builds Destination with QUrl::toPercentEncoding(_destination, "/"), which likewise percent-encodes #.
• Searches across the public issue/PR history of curl, rclone, Nextcloud Desktop, ownCloud Desktop, and Cyberduck found no evidence that normal operations from these clients emit a raw fragment-bearing WebDAV request-target.

Litmus is intentionally different. Its delete_fragment test deliberately:

1. creates a collection at frag/;
2. sends DELETE to frag/#ment;
3. emits a warning if the server deletes frag/.

This is an adversarial robustness probe, not representative traffic from a normal WebDAV client. Litmus records it as a protocol warning rather than making the entire basic suite fail.

AsterDrive threat model

AsterDrive currently serves personal workspaces publicly, while team membership is invitation-only. WebDAV mutation also requires valid WebDAV credentials and the caller's existing workspace/team permissions.

Under the currently verified behavior:

• there is no anonymous mutation path;
• there is no demonstrated personal-to-personal or personal-to-team authorization bypass;
• the caller must already have mutation permission for the truncated resource;
• mainstream clients normally strip a real URI fragment or encode a filename # as %23;
• an authenticated caller with suitable permission could already mutate the same resource through a normal request.

The impact remains potentially high inside the caller's authorized scope if a malformed request reaches the parser, especially for recursive collection deletion. However, normal-client likelihood is very low and no privilege expansion has been demonstrated. This is therefore best classified as a low-priority data-integrity/parser differential, rather than a high-priority authorization vulnerability.

Upstream boundary

The root cause is tracked broadly in hyperium/http#127. The issue now contains an explicit WebDAV/Litmus report about unsafe DELETE behavior:

• WebDAV unsafe DELETE report
• Litmus delete_fragment explanation

In the current Actix stack, the raw request-target is still available in the HTTP/1 decoder, but http::Uri discards the fragment before AsterDrive's handler receives the request. A clean fix therefore belongs at the parser boundary or in an accepted upstream dependency change; handler-level validation sees the target after information loss.

We should reassess the priority if any of the following occurs:

• a mainstream WebDAV client is confirmed to emit raw # during normal operation;
• a cross-workspace or cross-permission path mismatch is demonstrated;
• anonymous/share mutation begins using this path;
• a real user encounters fragment-related misdirected mutation;
• Actix or http provides an upstream parser-boundary fix suitable for adoption.