okhttp logging interceptor: EOFException on OPTIONS response



  • 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