okhttp logging interceptor: EOFException on OPTIONS response



  • 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


  • developer

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



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


  • developer

    @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


  • developer

    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.


  • developer

    @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


  • developer

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


  • developer

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



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


  • developer

    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.



  • I changed our http handler to disable compression in case of zero length body and everything works as expected. New sync*gw version is available at rc.syncgw.com.

    Thank you for your input and support.


  • developer

    See also:

    @synncgw May I ask which gzip handler you use or which algorithm it uses?



  • $body = gzencode($body 4, $enc == 'gz' ? FORCE_GZIP : FORCE_DEFLATE);
    

    Depending on requested compression. See https://www.php.net/manual/de/function.gzencode.php


  • developer

    @synncgw Thanks. But I don’t understand it, because

    <?php
    print strlen(gzencode(null, 4, FORCE_GZIP))."\n";
    print strlen(gzencode("", 4, FORCE_GZIP))."\n";
    

    prints

    20
    20
    

    here (PHP 7.2.18). I didn’t manage to make it return an empty string.

    How would gzencode have to be called so that it returns a string with length 0?



  • You’re right, but my programmer seems to be clever 🙂 They first checks body length (which is ‘’ == 0) and then skip compression header…

    Response: HTTP/1.1 200 Ok
    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-Length: 0
    

    Thus, compression is not mentioned. In “old code” an additional header is send:

    = Response: HTTP/1.1 200 Ok
    = 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-Length: 0
    + Content-Encoding: gzip
    

    causing DAVx to crash.


  • developer

    @synncgw I see, so the server previously sent Content-Encoding: gzip without actually using gzencode(), which caused the problems (no crash 😏).

    In my opinion, okhttp/okio should accept 0-octet gzip responses nevertheless, but the specific problem should be fixed with your changes, so I have marked the topic as solved.


Log in to reply