Re: [ietf-caldav] <DAV:href> and invalid URL characters

[Julian Reschke <[e-mail]>]

Gren Elliot wrote:
> Hi,
> 
> Seeking some thoughts or a pointer to a definitive answer, as I can't 
> see an immediate, definitive answer in the WebDAV spec.
> 
> We sometimes find that a CalDAV client ends up choosing the final 
> element of the path name for a new calendar entry using a PUT similar to :
> 
> PUT 
> /api/dav/Calendars/Users/[e-mail]/Calendar/%7BCA-GREN-49B1-233%7D.ics 
> HTTP/1.1
> 
> %7B happens to be the way you would encode "{" in a URL and %7D for "}", 
> these characters not being valid in a well formed URL.

Looks good so far.

> The same client then later asks for the same entry using :
> REPORT /api/dav/Calendars/Users/[e-mail]/Calendar/ HTTP/1.1
> ...
> 
> <?xml version="1.0" encoding="UTF-8" ?>
> <x0:calendar-multiget xmlns:x0="urn:ietf:params:xml:ns:caldav" 
> xmlns:x1="DAV:">
> <x1:prop>
> <x1:getetag/>
> <x0:calendar-data/>
> </x1:prop>
> <x1:href>/api/dav/Calendars/Users/[e-mail]/Calendar/{CA-GREN-49B1-233}.ics</x1:href>
> </x0:calendar-multiget>

That's, stricly speaking, a malformed request, as the contents of 
DAV:href is syntactically invalid.

> and is not happy when it gets the response :
> 
> <D:multistatus xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:D="DAV:">
> <D:response>
> <D:href>/api/dav/Calendars/Users/[e-mail]/Calendar/%7BCA-GREN-49B1-233%7D.ics</D:href>
> <D:propstat>
> <D:prop>
> <D:getetag>8</D:getetag>
> <C:calendar-data>BEGIN:VCALENDAR&#13;
> CALSCALE:GREGORIAN&#13;
> ...

It should be more than happy with it :-)

> So, my question is, what should go in <DAV:href>?  A well formed URL 
> with correct encoding or is it OK (or even more correct?) to translate 
> to the more visually friendly form?  Theoretically, in this particular 
> case, the response could follow whatever was used in the request but...

Nope.

RFC 4918 (WebDAV) requires the content to be a URI or a relative 
reference. You're not doing anybody a favor by working around client 
bugs; instead I'd recommend to contact the authors of the client and get 
it fixed.

BR, Julian