Yes, Google is changing a lot all the time and they deprecated older APIs recently. Some people report its working, but we’ve now disabled the entry again, because it makes too much trouble for us to support a service which constantly changes and which is also not very well tested by Google itself.
okhttp logging interceptor: EOFException on OPTIONS response
-
Hi,
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. -
Hello,
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://192.168.10.100/sgw/sync.php/principals/t1@wb28.de/ 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?
-
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:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding
-
@j-ed DAVx⁵ supports compression on various occasions. Gzip compression should work. Uncompressed answers are only requested when required, for instance when
GET
ting a resource where theETag
is relevant. -
Webserver
XAMPP Apache/2.4.39 (Win64) OpenSSL/1.1.1b PHP/7.3.4
User-Agent
DAVx5/2.4.0.1-ose (2019/04/05; dav4jvm; okhttp/3.12.1) Android/8.1.0
sends
Accept-Encoding: gzip
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.
-
Hi, I checked with a test server in internet. Same behavior. Pls take a look @ attached files .DAVx⁵ 2.4.0.1-ose debug info .htaccess access_ssl_log
-
@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
OPTIONS
request which is used to determine whether an URL is CalDAV/CardDAV-capable causes anEOFException
in okhttp’s logging interceptor which is used by DAVx⁵ (but works withcurl
). 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
OPTIONS
request withAccept-Encoding: gzip
, the server sends an empty response (0 bytes) together withContent-Encoding: gzip
:$ curl -vX OPTIONS -u 'test04@syncgw.com:xxxxxxxxxx' -vH 'Accept-Encoding: deflate,gzip' 'https://rc.syncgw.com/sync.php/principals/test04@syncgw.com/' … * SSL certificate verify ok. * Server auth using Basic with user 'test04@syncgw.com' > OPTIONS /sync.php/principals/test04@syncgw.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: gzip
with a 0 byte response is intentional? Does it work when you completely disablegzip
compression or at least don’t send 0-byte gzip responses? You can check whether it’s really off with thecurl
command given above.