After syncing problems I made a full deinstallation of DAVdroid (including JB Workaround).
After reinstallation of DAVdroid, now version 1.0.9.2, I am not able to establish a data connection to my owncloud server:
No CalDAV, no CardDAV Service found.
DAVdroid log shows a 411 length error (see attached DAVdroid log).
0_1465919923199_davdroid-debug562138376.txt
The client with the DAVdroid problem:
Android version: 6.0.1 (MOB30M)
Device: Motorola Nexus 6 (shamu)
With another client, but same DAVdroid version 1.0.9.2 and syncing with the same OC server under the same OC Account shows no problems:
Android version: 5.0.1
Device: Samsung S5
Owncloud Server was changed last in December 2015, running now with OC 8.2.2
2016-06-14 13:39:58 2 [HttpClient$1] --> OPTIONS https://myDomain.de/owncloud/remote.php/carddav/principals/georg/ http/1.1
2016-06-14 13:39:58 2 [HttpClient$1] --> END OPTIONS
2016-06-14 13:39:58 2 [HttpClient$1] <-- 411 https://myDomain.de/owncloud/remote.php/carddav/principals/georg/ (28ms)
2016-06-14 13:39:58 2 [HttpClient$1] date: Tue, 14 Jun 2016 11:39:57 GMT
2016-06-14 13:39:58 2 [HttpClient$1] server: Apache
2016-06-14 13:39:58 2 [HttpClient$1] content-length: 242
2016-06-14 13:39:58 2 [HttpClient$1] content-type: text/html; charset=iso-8859-1
2016-06-14 13:39:58 2 [HttpClient$1]
2016-06-14 13:39:58 2 [HttpClient$1] <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>411 Length Required</title>
</head><body>
<h1>Length Required</h1>
<p>A request of the requested method OPTIONS requires a valid Content-length.<br />
</p>
</body></html>
2016-06-14 13:39:58 2 [HttpClient$1] <-- END HTTP (242-byte body)
In my opinion, this is quite creative server behavior because OPTIONS requests usually don’t have a body (in contrast to a well-defined, zero-length body like in POST), as such a body is not even defined in current HTTP versions.
Are you server admin? Which server do you use? Are there any forwarding proxies?
Can you maybe provide a test account?
Small Provider with shared LAMP hosting.
PHP tells me:
PHP 5.6.22-pl0-gentoo (FPM)
How to send a PM with test account of my Owncloud installation?
Thanks for the credentials.
This is super-strange, I can reproduce the problem with DAVdroid, but not with curl …
Seems to work when disabling HTTP/2. So this seems to be another HTTP/2 problem … and I will have to debug that without being able to read/write the communications directly. Thanks, Google 
In the meanwhile, you could ask your provider to disable HTTP/2. Maybe we will also provide a DAVdroid option to disable this … Would also be interesting to know their setup (which Apache version, how HTTP/2 is provided, if there are forwarding proxies etc.).
I was able to capture the failing request using mitmproxy:
Request:
OPTIONS /xxx/remote.php/carddav/principals/bitfire/ HTTP/2.0
:method: OPTIONS
:path: /xxx/remote.php/carddav/principals/bitfire/
:authority: xxxdomain.de
:scheme: https
accept-encoding: identity
cookie: oc_sessionPassphrase=CXlmDs1%2FwUpwtbMSuAw5h1F2XPIDgcL%2Fq3TNAHQGFI1StsXijz16fKwcxQFw1SGTGokq7cof%2Bupo1UBu9Ac%2F35a0VZ2Ib8qrqrFHg16Id9TeXlo6D2D6JG%2BwKiBA8F7z; occd3fe1ecae=rorto1rl5dioi4r8licjljvtj1
user-agent: DAVdroid/1.0.9.2 (2016/06/15; dav4android; okhttp3) Android/6.0.1
accept-language: en-US, en;q=0.7, *;q=0.5
authorization: Basic xxxxxxxxxx
host: xxxdomain.de
Response:
HTTP/2.0 411
:status: 411
date: Wed, 15 Jun 2016 12:34:18 GMT
server: Apache
content-length: 242
content-type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>411 Length Required</title>
</head><body>
<h1>Length Required</h1>
<p>A request of the requested method OPTIONS requires a valid Content-length.<br />
</p>
</body></html>
However, when replaying the same request with mitmproxy, the server replies with 200 OK. So I guess the problem must be somewhere in the deep stream handling details of okhttp/the server (although I don’t know how these details could cause a HTTP 411 error). And honestly, debugging becomes really awkward now …
@rfc2822 :
My provider had now disabled HTTP/2.
And my Life is back:
my personal assistant could tell me again what to do on the next days and how to contact my friends ;-))
Same time when problems started with DAVdroid I had also problems with Thunderbird.
After deactivating http/2 in Thunderbird config:
network.http.spdy.enabled.http2
everything was fine with Thunderbird again.
So - nevertheless my problems are solved by my current provider - but as a user of DAVdroid I would like to be enabled to disable HTTP/2 in DAVdroid ;-))
Many thanks for Your quick Response and debugging efforts - and identifying HTTP/2 as the big problem.
Sorry for digging out this old topic, but I have the same error…
I’m running sabre/katana 0.4.2 as DAV server (shipping with sabre/dav 3.0.5), did also test baikal in version 0.4.6 (using sabre/dav 3.1.4).
My provider upgraded a few months ago to Apache 2.4 and enabled http/2. Disabling http/2 in Thunderbird did the trick for the sync problems on my computer, DAVdroid continued to work as expected. A few days ago my phone broke, got a new one. Now I cannot create my account anymore, DAVdroid gives me the error message no DAV-Server found.
Log: pastebin
Client details:
Android version: 6.0.1
Device: HTC One A9 (hiaeul)
Rom: Cyanogenmod 13, nightly 29161001
DAVdroid: 1.3.1-ose (from F-Droid)
Did also test this with my old Phone (Samsung Galaxy S4 Active GT-I9295 with cm12) and with my dad’s phone (Galaxy S4 mini, cm13), syncing with a existing account (account installed prior to Apache 2.4 migration) works, new account does not.
Disabling http/2 on server side is not an option, my provider does not support this.
Is there anything I can do about this (except changing my provider)? Happy to provide test accounts (baikal and katana).
@mic Can you please provide a test account? play@bitfire.at (OpenPGP key)
I still don’t see the link between HTTP/2 and OPTIONS suddenly requiring a Content-Length …
@mic Thanks for the test accounts, I was now able to identify the problem:
It’s all about the OPTIONS request. Basically, it can be sent with or without request body. Currently, an OPTIONS request body has no defined semantic value and is not required for DAVdroid’s purposes, so we choose to send the request without request body.
With HTTP/1.1, it’s quite easy. The request is sent as
OPTIONS /path HTTP/1.1
without Content-Length and request body, and everything works fine.
However, with HTTP/2, it becomes more difficult, because there are DATA frames. If a request has no body, no DATA frame should be sent. However, okhttp sends an empty DATA frame with 0 bytes:
davdroid.DavResourceFinder: [HttpClient$1] --> OPTIONS https://yourserver/katana/public/server.php/principals/bitfire/ http/1.1
davdroid.DavResourceFinder: [HttpClient$1] --> END OPTIONS
davdroid.dav4android: [dav4android.BasicDigestAuthHandler] Adding Basic authorization header for https://yourserver/katana/public/server.php/principals/bitfire/
okhttp3.internal.framed.Http2$FrameLogger: [okhttp3.internal.framed.Http2$Writer] >> 0x0000001f 218 HEADERS END_HEADERS
[!!!] okhttp3.internal.framed.Http2$FrameLogger: [okhttp3.internal.framed.Http2$Writer] >> 0x0000001f 0 DATA END_STREAM
okhttp3.internal.framed.Http2$FrameLogger: [okhttp3.internal.framed.Http2$Reader] << 0x0000001f 7 HEADERS END_HEADERS
although dav4android specifies a request without body (body is null). The Apache 2.4 server then rejects the request because there’s a request body (i.e. data frame), but no Content-Length.
So, it seems to be an okhttp problem. I have reported this to okhttp and I’m waiting for response.
The problem can be simulated with nghttp, too:
nghttp -v -H ':method:OPTIONS' -H 'Authorization: Basic ***' https://yourserver/baikal/html/dav.php works as expected, while a 0-byte data frame without Content-Length, generated by
nghttp -v -d /dev/null --no-content-length -H ':method:OPTIONS' -H 'Authorization: Basic ***' https://yourserver/baikal/html/dav.php causes an error.
A workaround is to specify Content-Length: 0 in the OPTIONS request (so the request has a body, but with specified length, which is OK for the server, too). We’ll implement this for the next DAVdroid version until okhttp is fixed.
Hellio rfc2822
Thanks for your support! I’d like to quote Georg:
@Georg said in 411 length error, DAVdroid 1.0.9.2, Owncloud:
And my Life is back:
my personal assistant could tell me again what to do on the next days and how to contact my friends )
I did apply your fix, works flawless! Adding accounts (tested on several devices) and syncing changes over different devices works perfect.
Many thanks for your quick response and your help.
The workaround has now been released with DAVdroid 1.3.2.2.
BTW, this has been fixed in okhttp now.