Handling of URL encoding in server responses.
Hi, I'm looking at a strange little scenario with a client trying to sync with the CalendarServer. It goes 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 ... ================================================================= Now ... it's clear from https://tools.ietf.org/html/rfc4918#section-8.3 that the last request is illegal. Or rather... if one parses the URL comparison rules it seems to say that the Request-URI and the <href> should be octet-by-octet compared, so "@" != "%40" here. However... (and this is the question) ... I'm a little in doubt about how to interpret RFC4918, section 8.3 wrt. which rules the server should obey wrt. the Request-URI when formulating the response. Is the server allowed to respond with <href>/%40</href> when the Request-URI was /@ ? regards, Peter Mogensen
Hi Peter, --On August 10, 2016 at 9:41:29 AM +0200 Peter Mogensen <apm@one.com> wrote:
However... (and this is the question) ... I'm a little in doubt about how to interpret RFC4918, section 8.3 wrt. which rules the server should obey wrt. the Request-URI when formulating the response.
Is the server allowed to respond with <href>/%40</href> when the Request-URI was /@ ?
The @ character is being quoted: cyrus:~ cyrusdaboo$ python
import urllib urllib.quote("/me@you") '/me%40you'
So you need to make sure you unquote the DAV:href value before doing your comparison. Internally the server actually unquotes the request-URI as it is processed, and then when building the DAV:href re-quotes. So even though the request-URI used a "bare" @ symbol, it does get quoted in the output. -- Cyrus Daboo
On 2016-08-10 15:33, Cyrus Daboo wrote:
Hi Peter,
--On August 10, 2016 at 9:41:29 AM +0200 Peter Mogensen <apm@one.com> wrote:
However... (and this is the question) ... I'm a little in doubt about how to interpret RFC4918, section 8.3 wrt. which rules the server should obey wrt. the Request-URI when formulating the response.
Is the server allowed to respond with <href>/%40</href> when the Request-URI was /@ ?
So you need to make sure you unquote the DAV:href value before doing your comparison. Internally the server actually unquotes the request-URI as it is processed, and then when building the DAV:href re-quotes. So even though the request-URI used a "bare" @ symbol, it does get quoted in the output.
So - the server is not required to return the <href> URL's in the same encoding as the Request-URI. ... That was also my intuitive understanding, but I was not 100% sure of the interpretation. The client is not one I'm developing, but rather a 3rd party client where the developers say that the CalendarServer is doing it wrong. My impression was that this client is wrong by not formulating the last request with a Request-URI matching the encoding in the body. /Peter
Hi Peter, --On August 10, 2016 at 3:49:07 PM +0200 Peter Mogensen <apm@one.com> wrote:
So - the server is not required to return the <href> URL's in the same encoding as the Request-URI.
... That was also my intuitive understanding, but I was not 100% sure of the interpretation.
The client is not one I'm developing, but rather a 3rd party client where the developers say that the CalendarServer is doing it wrong.
My impression was that this client is wrong by not formulating the last request with a Request-URI matching the encoding in the body.
At the very first CalConnect interop event (over 10 years ago) we ran into many problems with URL encoding in multistatus responses etc. What we have now behaves according to everyone else's reading of how things work. I am afraid the client will have to change, we are very unlikely to make any change ourselves as the impact on existing clients is unknown. -- Cyrus Daboo
On 2016-08-10 15:52, Cyrus Daboo wrote:
My impression was that this client is wrong by not formulating the last request with a Request-URI matching the encoding in the body.
At the very first CalConnect interop event (over 10 years ago) we ran into many problems with URL encoding in multistatus responses etc. What we have now behaves according to everyone else's reading of how things work. I am afraid the client will have to change, we are very unlikely to make any change ourselves as the impact on existing clients is unknown.
Sure ... thanks for the input. /Peter
participants (2)
-
Cyrus Daboo
-
Peter Mogensen