DAVx5 bug with iCloud and URL percent escaping?

---

Hello,
I have tracked down a bug, I think. The issue is the same as documented here: https://gitlab.gnome.org/GNOME/evolution/issues/559#note_567589

To summarize the linked issue as best I can: it seems that the DAVx5 URL escaping is percent-encoding the “@” in the server-provided URL, and the URL normalization rules lead to the server considering that URL to be different than the original, un-encoded URL which it sent down.

To be precise, the server sends down the URL:
https://p42-caldav.icloud.com/168687870/calendars/b14f8cc34777ef002c0162652022216bb3e620952ff4ac76bebb035ef1109bb6/2uqfvi0md205ib7gusm7k3b8k2@googlecom.ics
If I download this URL manually, I get the correct ICS.

However, if I look at the DAVx5 logs, I see that the server is checking a version of the URL with the @ symbol percent escaped like so:
https://p42-caldav.icloud.com/168687870/calendars/b14f8cc34777ef002c0162652022216bb3e620952ff4ac76bebb035ef1109bb6/2uqfvi0md205ib7gusm7k3b8k2%40googlecom.ics

If I manually check this url, then the server gives me a 404!

The issue is with URL canonicalization. I am not an expert in this by any means, but the gnome bug report above says that the URL canonicalization should not escape @ symbols, as they are not in the class of characters which are considered equivalent to their percent-escaped selves.

Perhaps this is an easy fix! I hope this helps!

Hello,

Thanks for your report. Does the server send the URL with “@” as a PROPFIND result? Can you please post all relevant logs? Often, there are more than one variant and DAVx5 selects a specific one.

And we have fiddled around a lot to make it working in nearly all cases, so changing anything would have severe impact and is everything than an easy fix

So would have to look in depth at this case, which is why I’d need more logs.

@rfc2822 I will post logs! I need to reproduce this on my account rather than my wife’s, as she’s sick of me fussing with her phone.

@jonah Ok thanks!

Just FYI I’m still trying to reproduce this. The event which was previously triggering the 404 is now in the past, and doesn’t seem to be generating the 404 any more. Perhaps it’s not being synched. Anyhow, I will update this thread if I can make it happen again

@jonah Ok, thanks for your efforts!