Skip to content
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
Closed

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

mondonc opened this issue May 3, 2014 · 11 comments

Comments

@mondonc
Copy link
Contributor

@mondonc 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
Copy link
Member

@untitaker 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
Copy link
Member

@untitaker 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
Copy link
Member

@untitaker untitaker commented May 11, 2014

Ah, i do now.

untitaker added a commit that referenced this issue May 11, 2014
@mondonc
Copy link
Contributor Author

@mondonc mondonc commented May 12, 2014

Ok, thank you very much

@untitaker
Copy link
Member

@untitaker 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
Copy link
Member

@untitaker untitaker commented May 12, 2014

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

@untitaker untitaker changed the title Zimbra caldav compatibility 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
  - 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
Copy link
Member

@untitaker 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
Copy link

@eckhart 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 pushed a commit to eckhart/vdirsyncer that referenced this issue Jul 31, 2014
@untitaker
Copy link
Member

@untitaker 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
Copy link
Member

@untitaker 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
Copy link

@eckhart 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 #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 Special characters (@) in href are not correctly handled [was: Zimbra caldav compatibility] 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants