okhttp logging interceptor: EOFException on OPTIONS response

[syncgw]

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.

[rfc2822]

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.

[syncgw]

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?

[rfc2822]

@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).

[syncgw]

DAVx⁵ 2.4.0.1-ose debug info

[syncgw]

flows from https://mitmproxy.org/

[rfc2822]

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?

[j-ed]

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

[rfc2822]

@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 ETag is relevant.

[syncgw]

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.

[rfc2822]

@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

[rfc2822]

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

[syncgw]

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.

[rfc2822]

@synncgw I see. Maybe there’s another problem with your setup, but it really sounds like a connectivity problem and not a DAVx⁵ problem.

[syncgw]

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

[rfc2822]

@synncgw Can you provide a test account so that I can have a look?

[syncgw]

Required information send by chat functionality of forum (hope they arrived).

[rfc2822]

@synncgw Has arrived and I can confirm that the OPTIONS request which is used to determine whether an URL is CalDAV/CardDAV-capable causes an EOFException in 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?

[syncgw]

Yes, of course. Thank you again for your support. I’m looking forward to get your app working with our server.

[rfc2822]

When okhttp (DAVx⁵) sends the OPTIONS request with Accept-Encoding: gzip, the server sends an empty response (0 bytes) together with Content-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 disable gzip compression or at least don’t send 0-byte gzip responses? You can check whether it’s really off with the curl command given above.