.well-known/(caldav|carddav) returns 300 and breaks vdirsyncer

[mcmer]

vdirsyncer, version 0.15.0 DAV Server SOGo-2.3.12, frontend nginx-1.10.1, OS OpenBSD 6.0 amd64 Client python-3.6.0, OS OpenBSD 6.1 GENERIC.MP#209 amd64

CONFIG [general] status_path = "~/.vdirsyncer/status/"

[pair foobar_cal] a = "foobar_cal_local" b = "foobar_cal_remote" collections = ["from a", "from b"] metadata = ["displayname", "color"]

[storage foobar_cal_local] type = "filesystem" path = "~/.calendars/" fileext = ".ics"

[storage foobar_cal_remote] type = "caldav" url = "https://dav.server.dmn/SOGo/dav/foobar/" username = "foobar" password = "jodeswerdidoherschreibn"

DEBUG LOG vdirsyncer.txt

I think vdirsyncer is just not prepared for the "300 multiple choices" reply.

Marcus

[mcmer]

Just disabled the spell checking module which caused the 300 multiple choices response. This way vdirsyncer gets a 404 when querying .well-known/caldav and it keeps working.

[untitaker]

What does the spell checker even do that it affects DAV? I can totally just handle the 300 response as error and get on with it, but I'm not sure if that's a good bugfix.

Do well-known URIs work with other (popular) clients? I.e. do you need to use the full URI or not?

[mcmer]

When vdirsyncer requested /.well-known/caldav (which does not exist) it would have gotten a 404 but the spelling module jumped in and thought it had something similiar to offer.

It was just enabled for the entire server, not just this vhost. turned it off for the vhost. I have no idea why it was suggesting two non-working links to non-existing urls.

Before testing vdirsync I did not have the well-known redirects in my configs and other clients worked.

I wonder why vdirsyncer does not like the response of the server to the initial 'PROPFIND https://dav.serv.dmn/SOGo/dav/foobar/': Skipping, not of resource type {urn:ietf:params:xml:ns:caldav}calendar: <Element '{DAV:}response' at 0xaa756b52188>

Is this something the server (SOGo) should deliver but does not?

Then I'm also glad you do the caldav/carddav stuff ;-)

Thanks in advance! Marcus

[untitaker]

Before testing vdirsync I did not have the well-known redirects in my configs and other clients worked.

Sure, but what is the behavior of other clients with that plugin enabled? Do they handle status 300 correctly?

On Tue, Mar 07, 2017 at 03:28:24AM -0800, mcmer wrote:

When vdirsyncer requested /.well-known/caldav (which does not exist) it would have gotten a 404 but the spelling module jumped in and thought it had something similiar to offer.

It was just enabled for the entire server, not just this vhost. turned it off for the vhost. I have no idea why it was suggesting two non-working links to non-existing urls.

Before testing vdirsync I did not have the well-known redirects in my configs and other clients worked.

I wonder why vdirsyncer does not like the response of the server to the initial 'PROPFIND https://dav.serv.dmn/SOGo/dav/foobar/': Skipping, not of resource type {urn:ietf:params:xml:ns:caldav}calendar: <Element '{DAV:}response' at 0xaa756b52188>

Is this something the server (SOGo) should deliver but does not?

Then I'm also glad you do the caldav/carddav stuff ;-)

Thanks in advance! Marcus

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/pimutils/vdirsyncer/issues/584#issuecomment-284696200

[untitaker]

Could you provide a link to the spelling module you're talking about?

On 7 March 2017 12:28:24 CET, mcmer notifications@github.com wrote:

When vdirsyncer requested /.well-known/caldav (which does not exist) it would have gotten a 404 but the spelling module jumped in and thought it had something similiar to offer.

It was just enabled for the entire server, not just this vhost. turned it off for the vhost. I have no idea why it was suggesting two non-working links to non-existing urls.

Before testing vdirsync I did not have the well-known redirects in my configs and other clients worked.

I wonder why vdirsyncer does not like the response of the server to the initial 'PROPFIND https://dav.serv.dmn/SOGo/dav/foobar/': Skipping, not of resource type {urn:ietf:params:xml:ns:caldav}calendar: <Element '{DAV:}response' at 0xaa756b52188>

Is this something the server (SOGo) should deliver but does not?

Then I'm also glad you do the caldav/carddav stuff ;-)

Thanks in advance! Marcus

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/pimutils/vdirsyncer/issues/584#issuecomment-284696200

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[mcmer]

It's the hardened version of apache 1.3 of older OpenBSD. LoadModule speling_module /usr/lib/apache/modules/mod_speling.so

http://httpd.apache.org/docs/1.3/mod/mod_speling.html "This module attempts to correct misspellings of URLs that users might have entered, by ignoring capitalization and by allowing up to one misspelling."

source: https://github.com/fobser/apache-httpd-openbsd/blob/master/src/modules/standard/mod_speling.c

[untitaker]

Nevermind, I didn't read your debug log carefully enough.

[untitaker]

Please try out #585 by installing it with pipsi or similar, see https://vdirsyncer.pimutils.org/en/stable/installation.html#manual-installation

[mcmer]

Other clients:

firefox w/ mod_speling: Not Found The requested URL /.well-known/caldav was not found on this server.

firefox w/o mod_speling: Multiple Choices The document name you requested (/.well-known/caldav) could not be found on this server. However, we found documents with names similar to the one you requested. Available documents: /./caldav (common basename) /../caldav (common basename)

(both options are nonsense. no idea where it finds them!)

Thunderbird/Lightning: what happens on server when I specify the full path to my calender in lightning: PROPFIND /SOGo/dav/foobar/Calendar/personal/ OPTIONS /SOGo/dav/foobar/Calendar/ PROPFIND /SOGo/dav/foobar/ REPORT /SOGo/dav/foobar/Calendar/personal/

CalDAV-Sync/0.4.27 (samsung; serranoltexx; Android 4.4.2; de_AT; org.dmfs.caldav.lib/732; like iOS/5.0.1 (9A405) dataaccessd/1.0) with full path: PROPFIND /SOGo/dav/foobar/Calendar/personal/ PROPFIND /SOGo/dav/foobar/ PROPFIND /SOGo/dav/foobar/Calendar/personal/ PROPFIND /SOGo/dav/foobar/Calendar/

without full path, just https://dav.serv.dmn/: PROPFIND / HTTP/1.1 -> 404 PROPFIND /.well-known/caldav -> 404 [vdirsyncer does GET!] PROPFIND /SOGo/dav/ -> 207 (I have no idea how the client (android) knows of SOGo!) PROPFIND /SOGo/dav/foobar/ -> 207 PROPFIND / -> 404 PROPFIND /SOGo/dav/foobar/Calendar/

[untitaker]

I think #585 should solve your issue, but I'm curious: @dmfs, why does CalDAV-Sync send a PROPFIND against /.well-known/caldav?

[dmfs]

@untitaker that's standard procedure, specified in RFC 6764, see Point 5 in Section 6.

[untitaker]

Damn, you're right.

On 7 March 2017 15:32:59 CET, Marten Gajda notifications@github.com wrote:

@untitaker that's standard procedure, specified in RFC 6764, see Point 5 in Section 6.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/pimutils/vdirsyncer/issues/584#issuecomment-284737524

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[mcmer]

up to now I've manually applied https://patch-diff.githubusercontent.com/raw/pimutils/vdirsyncer/pull/585.diff

testing shows, with mod_speling on:

1) PROPFIND /SOGo/dav/foobar/ (full URI from config) -> 207 but does not like result: Skipping, not of resource type {urn:ietf:params:xml:ns:caldav}calendar: <Element '{DAV:}response' 2) GET /.well-known/caldav -> gets 300 (multiple choices) as result, does not like it NEW: debug: Server does not support well-known URIs. 3) PROPFIND /SOGo/dav/foobar/ (full URI from config) -> 207 4) PROPFIND /SOGo/dav/foobar/Calendar/ Skipping, not of resource type {urn:ietf:params:xml:ns:caldav}calendar: <Element '{DAV:}response' 5) PROPFIND /SOGo/dav/foobar/Calendar/personal finds calendar, continues to query other calendars and succeeds!

debug log: vdirsyncer.new.txt

Thanks, Marcus

[untitaker]

I'll close this issue, let's track the RFC violation in a new one.