Special characters (@) in href are not correctly handled #49
I'm trying to synchronize my zimbra calendar with owncloud.
First, I have to coment an assertion :
vdirsyncer/storage/dav.py", line 365, in list
Working on a set(), it is not a big problem.
But after, I am dealing with a true problem : some event contain a '@'. Sometimes, it is converted into '%40'.
I get something like :
I tried a lot of things with urllib.unquote or urllib.quote or replace() but after I get other exceptions (KeyError uid or KeyError item).
Can you understand my problem and have you any ideas ?
The text was updated successfully, but these errors were encountered:
I don't know what you mean by that. If you mean that this assertion is
Looking into the main problems of this bug is going to take me a few weeks, i
- Radicale incorrectly unquotes URLs - Older versions of radicale are so buggy they fail to look up items with url quotes in them. - ownCloud/SabreDAV follows the rebustness principle such that it takes anything, but returns properly encoded URLs. Conclusion: Send broken, unquoted URLs, because both sides seem to be happy with them. As wrong as it might seem, it works.
This actually creates a problem for me. My university's caldav-server returns properly encoded URLs containing Norwegian characters and after being 'unquoted' they aren't encoded correctly when requesting them, resulting in 404s (e.g. Gruppem%3Fte when it should be Gruppem%C3%98te). Removing all the unquote stuff fixes the problem in my case.
- Fix #49 -- The old fix caused problems with other servers. The new behavior only decodes ``@`` characters. - ``@`` is now not used when generating a new href, as some servers seem to have problems with it (http://sabre.io/dav/character-encoding/). This behavior is configurable via the ``unsafe_href_chars`` parameters for DAV storages, and is disabled in the testsuite for Radicale and ownCloud. - Decoding of hrefs is also done twice for CarddavStorage.list because of owncloud/contacts#581. Vdirsyncer has behaved like that before, but not intentionally. - Storages now don't share their ``_get_href`` methods anymore.