.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: #584 (comment)

[untitaker]

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

…

On 7 March 2017 12:28:24 CET, 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: #584 (comment)

-- 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