Failure creating items with %2f

[WhyNotHugo]

Actual behaviour

Creating an item such as /user/calendars/pZamv4UPiTOPuSM2/itemwith%2fslash.ics returns 404 Not Found.

Expected behaviour

This should create an item named itemwith%2fslash.ics inside the collection /user/calendars/pZamv4UPiTOPuSM2/.

Additional notes

My guess is that the URL is being percent-decoded BEFORE splitting the segments in the path, so Xandikos is trying to create an item named slash.ics insside the collection /user/calendars/pZamv4UPiTOPuSM2/itemwith.

[WhyNotHugo]

The log line from Xandikos reads:

172.17.0.1 [27/Dec/2024:10:41:20 +0000] "PUT /user/calendars/4B5LIYNjhHZcoKOb/itemwith%2fslash.ics HTTP/1.1" 404 226 "-" "-"

[WhyNotHugo]

The last parragraph of https://www.rfc-editor.org/rfc/rfc3986#section-2.2 is relevant here:

URIs that differ in the replacement of a reserved character with its
corresponding percent-encoded octet are not equivalent. Percent-encoding a
reserved character, or decoding a percent-encoded octet that corresponds to a
reserved character, will change how the URI is interpreted by most
applications. Thus, characters in the reserved set are protected from
normalization and are therefore safe to be used by scheme-specific and
producer-specific algorithms for delimiting data subcomponents within a URI.

So /user/calendars/4B5LIYNjhHZcoKOb/itemwith%2fslash.ics != /user/calendars/4B5LIYNjhHZcoKOb/itemwith/slash.ics

[WhyNotHugo]

Also relevant, from https://www.rfc-editor.org/rfc/rfc3986#section-7.3:

Percent-encoded octets must be decoded at some point during the dereference
process. Applications must split the URI into its components and subcomponents
prior to decoding the octets, as otherwise the decoded octets might be
mistaken for delimiters. Security checks of the data within a URI should be
applied after decoding the octets.

I'm aware that this is quite an edge case — I came across this scenario while testing pimsync for this edge case with different CalDAV implementations.