[GH-ISSUE #152] Handling of URL encoding in REPORT request

kerem commented

2026-02-25 20:31:00 +03:00

Owner

Originally created by @peter-mogensen on GitHub (Aug 10, 2016).
Original GitHub issue: https://github.com/aluxnimm/outlookcaldavsynchronizer/issues/152

Hi,

Sending REPORT request to a CalDAV server where the encoding in the Request-URI does not match the one used for URLs in elements is illegal (according to RFC4918, section 8.3 )

It seems this happens for this client when the Calendar Collection URL contains "@".

Like this - in summary:

C: REPORT:calendar-query /calendars/users/me@domain/calendar/
----------------------------------------------------------------
<?xml version="1.0"?>
                     <C:calendar-query 
xmlns:C="urn:ietf:params:xml:ns:caldav">
                         <D:prop xmlns:D="DAV:">
                             <D:getetag/>
                         </D:prop>
                         <C:filter>
                             <C:comp-filter name="VCALENDAR">
                                 <C:comp-filter name="VEVENT">
                                   <C:time-range 
start="20160611T000000Z" end="20170207T000000Z"/>
                                 </C:comp-filter>
                             </C:comp-filter>
                         </C:filter>
                     </C:calendar-query>
-----------------------------------------------------------------

S: 207 - Here's a bunch of hrefs of the form:
    <href>/calendars/users/me%40domain/calendar/blabla.ics</href>

C: REPORT:calendar-multiget /calendars/users/me@domain/calendar/
    <href>/calendars/users/me%40domain/calendar/blabla.ics</href
    ...

The last Request is illegal and results in a bunch of "Bad Request" responses.

Originally created by @peter-mogensen on GitHub (Aug 10, 2016). Original GitHub issue: https://github.com/aluxnimm/outlookcaldavsynchronizer/issues/152 Hi, Sending REPORT request to a CalDAV server where the encoding in the Request-URI does not match the one used for URLs in <href> elements is illegal (according to RFC4918, section 8.3 ) It seems this happens for this client when the Calendar Collection URL contains "@". Like this - in summary: ``` C: REPORT:calendar-query /calendars/users/me@domain/calendar/ ---------------------------------------------------------------- <?xml version="1.0"?> <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav"> <D:prop xmlns:D="DAV:"> <D:getetag/> </D:prop> <C:filter> <C:comp-filter name="VCALENDAR"> <C:comp-filter name="VEVENT"> <C:time-range start="20160611T000000Z" end="20170207T000000Z"/> </C:comp-filter> </C:comp-filter> </C:filter> </C:calendar-query> ----------------------------------------------------------------- S: 207 - Here's a bunch of hrefs of the form: <href>/calendars/users/me%40domain/calendar/blabla.ics</href> C: REPORT:calendar-multiget /calendars/users/me@domain/calendar/ <href>/calendars/users/me%40domain/calendar/blabla.ics</href ... ``` The last Request is illegal and results in a bunch of "Bad Request" responses.

kerem closed this issue

2026-02-25 20:31:00 +03:00

kerem commented

2026-02-25 20:31:00 +03:00

Author

Owner

@aluxnimm commented on GitHub (Aug 10, 2016):

We had some issues with older Owncloud servers and double encoding or wrong encodings in hrefs from server responses. What server are you using? What happens if you use the %40 inside the DAV url when configuring the sync profile?

@aluxnimm commented on GitHub (Aug 10, 2016): We had some issues with older Owncloud servers and double encoding or wrong encodings in hrefs from server responses. What server are you using? What happens if you use the %40 inside the DAV url when configuring the sync profile?

kerem commented

2026-02-25 20:31:00 +03:00

Author

Owner

@peter-mogensen commented on GitHub (Aug 11, 2016):

It's Apples CalendarServer.

I've confirmed with Apple that it is intented behavior of the server to reply with %40 even if the Request-URI is "@".
So the Outlook plugin needs to parse the returned hrefs and formulate the next request so Request-URI matches the href in the multiget body.

Using %40 when configuring is a work-around at present it seems.
But that would in principle require that the server also replies with %40 during any auto-discovery (via DNS and .well-known) ... I believe the CalendarServer does this, but one could probably not in general relying on servers doing that.

BTW ... We've tested this on an Windows 10/ Outlook 2016 and I have followed the link form sourceforge to here, so I assume this is the source code. Please excuse me if there has been forks of the sourceforge project and I'm posting this the wrong place.
https://sourceforge.net/projects/outlookcaldavsynchronizer/

@peter-mogensen commented on GitHub (Aug 11, 2016): It's Apples CalendarServer. I've confirmed with Apple that it is intented behavior of the server to reply with %40 even if the Request-URI is "@". So the Outlook plugin needs to parse the returned hrefs and formulate the next request so Request-URI matches the href in the multiget body. Using %40 when configuring is a work-around at present it seems. But that would in principle require that the server also replies with %40 during any auto-discovery (via DNS and .well-known) ... I believe the CalendarServer does this, but one could probably not in general relying on servers doing that. BTW ... We've tested this on an Windows 10/ Outlook 2016 and I have followed the link form sourceforge to here, so I assume this is the source code. Please excuse me if there has been forks of the sourceforge project and I'm posting this the wrong place. https://sourceforge.net/projects/outlookcaldavsynchronizer/

kerem commented

2026-02-25 20:31:00 +03:00

Author

Owner

@evert commented on GitHub (Aug 11, 2016):

The problem here is that the client uses string matching to determine equivalence in urls. This is far to simplistic, and it probably means you have other bugs too.

You should normalize every URI before comparing it.

@evert commented on GitHub (Aug 11, 2016): The problem here is that the client uses string matching to determine equivalence in urls. This is far to simplistic, and it probably means you have other bugs too. You should normalize every URI before comparing it.

kerem commented

2026-02-25 20:31:00 +03:00

Author

Owner

@peter-mogensen commented on GitHub (Aug 11, 2016):

I actually don't think this specific issue is about "comparison" in the client per se.
The final REPORT:calendar-multiget request which the client sends is semantically good enough... it's just that the client cannot blindly copy-paste URLs from the previous 207 answer from the server into the multiget request while at the same time keep using the same syntax in the Request-URI.

The client has to ensure in every request it makes containing URLs in the body that the same encoding is used in the elements as in the Request-URI.

@peter-mogensen commented on GitHub (Aug 11, 2016): I actually don't think this specific issue is about "comparison" in the client per se. The final REPORT:calendar-multiget request which the client sends is semantically good enough... it's just that the client cannot blindly copy-paste URLs from the previous 207 answer from the server into the multiget request while at the same time keep using the same syntax in the Request-URI. The client has to ensure in every request it makes containing URLs in the body that the _same_ encoding is used in the <href> elements as in the Request-URI.

kerem commented

2026-02-25 20:31:00 +03:00

Author

Owner

@aluxnimm commented on GitHub (Aug 11, 2016):

Actually, we compare the unescaped uris to determine equivalence.
Since the C# Uri class had some issues we wrote a wrapper WebResourceName.cs

But need to investigate in detail what happens here and need to remember the issues we had with Owncloud, that was the main reason we changed that code.

@aluxnimm commented on GitHub (Aug 11, 2016): Actually, we compare the unescaped uris to determine equivalence. Since the C# Uri class had some issues we wrote a wrapper [WebResourceName.cs](https://github.com/aluxnimm/outlookcaldavsynchronizer/blob/master/CalDavSynchronizer/DataAccess/WebResourceName.cs) But need to investigate in detail what happens here and need to remember the issues we had with Owncloud, that was the main reason we changed that code.

kerem commented

2026-02-25 20:31:00 +03:00

Author

Owner

@aluxnimm commented on GitHub (Aug 15, 2016):

Should be fixed in 2.4.0.

@aluxnimm commented on GitHub (Aug 15, 2016): Should be fixed in 2.4.0.

kerem commented

2026-02-25 20:31:00 +03:00

Author

Owner

@rfc2822 commented on GitHub (Aug 16, 2016):

You should normalize every URI before comparing it.

I ran into the same problem and thought so, too. See https://github.com/square/okhttp/issues/1916 why this is not always a good idea (it especially hit me hard that GET https://github.com/square/%6fkhttp returns an error, while GET https://github.com/square/okhttp returns 200).

However, in WebDAV context, I think it's safe (and a better solution) to decode URL components before comparing them. For dav4android/DAVdroid, we use decoding for comparison, but access every resource with the same URL as sent by the server.

@rfc2822 commented on GitHub (Aug 16, 2016): > You should normalize every URI before comparing it. I ran into the same problem and thought so, too. See https://github.com/square/okhttp/issues/1916 why this is not always a good idea (it especially hit me hard that `GET https://github.com/square/%6fkhttp` returns an error, while `GET https://github.com/square/okhttp` returns 200). However, in WebDAV context, I think it's safe (and a better solution) to decode URL components before comparing them. For dav4android/DAVdroid, we use [decoding for comparison](https://gitlab.com/bitfireAT/dav4android/blob/master/src/main/java/at/bitfire/dav4android/UrlUtils.java#L10), but access every resource with the same URL as sent by the server.

kerem commented

2026-02-25 20:31:00 +03:00

Author

Owner

@aluxnimm commented on GitHub (Aug 16, 2016):

yes we do exactly the same thing now, sounds reasonable.

@aluxnimm commented on GitHub (Aug 16, 2016): yes we do exactly the same thing now, sounds reasonable.

kerem commented

2026-02-25 20:31:00 +03:00

Author

Owner

@evert commented on GitHub (Aug 16, 2016):

That would be my exact suggestion too. Don't rewrite urls, only normalize for comparing.
If it helps I can point you to the algorithm I wrote
On Aug 16, 2016 4:14 PM, rfc2822 notifications@github.com wrote:
You should normalize every URI before comparing it.

I ran into the same problem and thought so, too. See square/okhttp#1916 why this is not always a good idea (it especially hit me hard that GET https://github.com/square/%6fkhttp returns an error, while GET https://github.com/square/okhttp returns 200).

However, in WebDAV context, I think it's safe (and a better solution) to decode URL components before comparing them. For dav4android/DAVdroid, we use decoding for comparison, but access every resource with the same URL as sent by the server.

—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.

@evert commented on GitHub (Aug 16, 2016): That would be my exact suggestion too. Don't rewrite urls, only normalize for comparing. If it helps I can point you to the algorithm I wrote On Aug 16, 2016 4:14 PM, rfc2822 notifications@github.com wrote: You should normalize every URI before comparing it. I ran into the same problem and thought so, too. See square/okhttp#1916 why this is not always a good idea (it especially hit me hard that GET https://github.com/square/%6fkhttp returns an error, while GET https://github.com/square/okhttp returns 200). However, in WebDAV context, I think it's safe (and a better solution) to decode URL components before comparing them. For dav4android/DAVdroid, we use decoding for comparison, but access every resource with the same URL as sent by the server. —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.

kerem referenced this issue

2026-03-01 17:40:21 +03:00

[GH-ISSUE #148] Trouble synchronizing recurring events created for different timezones - Outlook 2013. #614

kerem referenced this issue

2026-03-14 00:01:25 +03:00

[GH-ISSUE #148] Trouble synchronizing recurring events created for different timezones - Outlook 2013. #1046

Rows
Columns

[GH-ISSUE #152] Handling of URL encoding in REPORT request #148