Great, thanks for the update. You’ve got a very fancy avatar
okhttp logging interceptor: EOFException on OPTIONS response
please check out https://github.com/sabre-io/dav/issues/1153. It is likely you client does not follow protocol specifications and can therefore not sync. with at least SabreDAV.
I don’t see any problem here. DAVx⁵ tries to find an address book homeset at various locations (including the principal URL, of course) and there is no problem when the server returns 404 for some URLs.
Please provide an exact description of the problem, including DAVx5 detection logs. Synchronzation between DAVx⁵ and SabreDAV is working well for various servers.
The problem is, there is a address book available. SabreDAV cannot handle such a combined request from DAVx and therefore DAVx thinks there is no address book available (which is available). In consequence address book is not synchronized. Would a mitm trace be helpful?
@synncgw Sounds strange, this should not happen. These requests are well-defined in WebDAV and there are many SabreDAV implementations working with DAVx⁵, so I guess the problem comes from a specific implementation. Which one is it?
Would a mitm trace be helpful?
Better than nothing, but please provide the detection logs of DAVx⁵ (View logs / then Send).
Thanks for the DAVx⁵ logs. As one can see, your problems are not related to WebDAV, but to HTTP gzip compression:
2019-05-15 05:44:21 391 [ui.setup.DavResourceFinder] Couldn't detect services on http://email@example.com/ EXCEPTION java.io.EOFException at okio.RealBufferedSource.require(RealBufferedSource.kt:55) at okio.GzipSource.consumeHeader(GzipSource.kt:104) at okio.GzipSource.read(GzipSource.kt:62) at okio.RealBufferedSource.request(RealBufferedSource.kt:62) at okhttp3.logging.HttpLoggingInterceptor.intercept(HttpLoggingInterceptor.java:253)
Which kind of Web server and compression do you use? Can you try to disable it to see whether that helps?
j-ed last edited by
Just out of curiosity, does DAVx5 send any header related to compression? As far as I understood an uncompressed answer can be requested by the client by sending the right HTTP header:
@j-ed DAVx⁵ supports compression on various occasions. Gzip compression should work. Uncompressed answers are only requested when required, for instance when
GETting a resource where the
XAMPP Apache/2.4.39 (Win64) OpenSSL/1.1.1b PHP/7.3.4
DAVx5/188.8.131.52-ose (2019/04/05; dav4jvm; okhttp/3.12.1) Android/8.1.0
That’s why syncgw.com response with gzip compression. I disabled compressed responses, but behavior is exactly the same.
@synncgw Which HTTP version do you use? HTTP/2? Does it help to disable it?
If you can provide a test account, I can also have a look
Maybe the compression isn’t the real problem. EOF means that the stream has been interrupted. Are there any firewalls involved? Did you have a look at your Web server error logs? Firewall logs? Did you try another network type (mobile/WiFi)?
For testing purpose I use a local XAMPP installation with an Android emulator (Version 27). Thus, DAVx is connecting to local IP using IP stack (no WiFi, no cable). I’ll check if I can disable Win10 firewall and try sync. with our internet server and report results.
@synncgw I see. Maybe there’s another problem with your setup, but it really sounds like a connectivity problem and not a DAVx⁵ problem.
@synncgw Can you provide a test account so that I can have a look?
Required information send by chat functionality of forum (hope they arrived).
@synncgw Has arrived and I can confirm that the
OPTIONSrequest which is used to determine whether an URL is CalDAV/CardDAV-capable causes an
EOFExceptionin okhttp’s logging interceptor which is used by DAVx⁵ (but works with
curl). Unfortunately, I don’t have much time to look at it now. Can you keep the test account online for some time or even have a look at how okhttp/curl handle the response?
Yes, of course. Thank you again for your support. I’m looking forward to get your app working with our server.
When okhttp (DAVx⁵) sends the
Accept-Encoding: gzip, the server sends an empty response (0 bytes) together with
$ curl -vX OPTIONS -u 'firstname.lastname@example.org:xxxxxxxxxx' -vH 'Accept-Encoding: deflate,gzip' 'https://email@example.com/' … * SSL certificate verify ok. * Server auth using Basic with user 'firstname.lastname@example.org' > OPTIONS /email@example.com/ HTTP/1.1 > Host: rc.syncgw.com > Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxxx > User-Agent: curl/7.58.0 > Accept: */* !!! > Accept-Encoding: deflate,gzip !!! > < HTTP/1.1 200 OK < Date: Mon, 20 May 2019 15:35:02 GMT < Server: Apache < X-Powered-By: PHP/7.3.5 < Expires: Thu, 19 Nov 1981 08:52:00 GMT < Pragma: no-cache < Cache-Control: private < X-Sabre-Version: 3.2.2 < Allow: OPTIONS, GET, HEAD, DELETE, PROPFIND, PUT, PROPPATCH, COPY, MOVE, REPORT < DAV: 1, 3, extended-mkcol, addressbook, access-control, calendarserver-principal-property-search < MS-Author-Via: DAV < Accept-Ranges: bytes !!! < Content-Encoding: gzip !!! < Set-Cookie: roundcube_sessid=q9344gb2j6280oiqhmour1hglh; path=/; secure; HttpOnly !!! < Content-Length: 0 !!! < X-Powered-By: PleskLin < X-Robots-Tag: noindex, nofollow < Content-Type: text/html; charset=UTF-8 < * Connection #0 to host rc.syncgw.com left intact
According to https://github.com/square/okhttp/issues/1550, this is not valid, but after studying RFC 1952, I’m not sure. Will have to investigate further.
@synncgw Do you know whether
Content-Encoding: gzipwith a 0 byte response is intentional? Does it work when you completely disable
gzipcompression or at least don’t send 0-byte gzip responses? You can check whether it’s really off with the
curlcommand given above.