New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Special characters (@) in href are not correctly handled #49

Closed
mondonc opened this Issue May 3, 2014 · 11 comments

Comments

Projects
None yet
3 participants
@mondonc
Contributor

mondonc commented May 3, 2014

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
assert href not in hrefs
AssertionError

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 :
File "vdirsyncer/storage/dav.py", line 186, in get_multi
.format(href, hrefs_left))
KeyError: "/owncloud/remote.php/caldav/calendars/xx/yy/myname%40mycompany-225654.ics doesn't exist in set([u'/owncloud/remote.php/caldav/calendars/xx/yy/myname@mycompagny-225654.ics'])"

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 ?

@untitaker

This comment has been minimized.

Member

untitaker commented May 9, 2014

First, I have to coment an assertion :

vdirsyncer/storage/dav.py", line 365, in list
assert href not in hrefs
AssertionError

Working on a set(), it is not a big problem.

I don't know what you mean by that. If you mean that this assertion is
unnecessary, i don't see why.

Looking into the main problems of this bug is going to take me a few weeks, i
am very busy right now.

@untitaker

This comment has been minimized.

Member

untitaker commented May 11, 2014

Unfortunately i don't seem to be able to reproduce this bug. Can you give an example ics file?

@untitaker

This comment has been minimized.

Member

untitaker commented May 11, 2014

Ah, i do now.

untitaker added a commit that referenced this issue May 11, 2014

@mondonc

This comment has been minimized.

Contributor

mondonc commented May 12, 2014

Ok, thank you very much

@untitaker

This comment has been minimized.

Member

untitaker commented May 12, 2014

Furthermore i am not sure whether this is a bug in owncloud. Could you contact the owncloud devs (e.g. in IRC) please?

untitaker added a commit that referenced this issue May 12, 2014

@untitaker

This comment has been minimized.

Member

untitaker commented May 12, 2014

Actually this is a bug in Radicale. I filed Kozea/Radicale#158

@untitaker untitaker changed the title from Zimbra caldav compatibility to Special characters (@) in href are not correctly handled [was: Zimbra caldav compatibility] May 12, 2014

untitaker added a commit that referenced this issue May 13, 2014

untitaker added a commit that referenced this issue May 13, 2014

Possible fix for #49
  - 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.

@untitaker untitaker closed this in 0cd4129 May 13, 2014

@untitaker

This comment has been minimized.

Member

untitaker commented May 13, 2014

Should be fixed in master. Please run

pip install --force-reinstall git+git://github.com/untitaker/vdirsyncer.git 

@untitaker untitaker added the bug label May 13, 2014

@eckhart

This comment has been minimized.

eckhart commented Jul 31, 2014

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.

eckhart added a commit to eckhart/vdirsyncer that referenced this issue Jul 31, 2014

@untitaker

This comment has been minimized.

Member

untitaker commented Aug 4, 2014

%C3%98 is Ø decoded, which seems to be fine. However, %3F is ? (a simple questionmark), which is surprising to say the least...

@untitaker untitaker reopened this Aug 4, 2014

untitaker added a commit that referenced this issue Aug 4, 2014

@untitaker

This comment has been minimized.

Member

untitaker commented Aug 4, 2014

@eckhart can you try the href_quoting branch?

untitaker added a commit that referenced this issue Aug 4, 2014

@eckhart

This comment has been minimized.

eckhart commented Aug 4, 2014

Seems to work, thanks!

untitaker added a commit that referenced this issue Aug 4, 2014

untitaker added a commit that referenced this issue Aug 4, 2014

untitaker added a commit that referenced this issue Aug 6, 2014

Fix all known URL-quoting problems
- 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.

@untitaker untitaker closed this in eb1431e Aug 6, 2014

@untitaker untitaker changed the title from Special characters (@) in href are not correctly handled [was: Zimbra caldav compatibility] to Special characters (@) in href are not correctly handled Dec 26, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment