okhttp logging interceptor: EOFException on OPTIONS response
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 'email@example.com:xxxxxxxxxx' -vH 'Accept-Encoding: deflate,gzip' 'https://firstname.lastname@example.org/' … * SSL certificate verify ok. * Server auth using Basic with user 'email@example.com' > OPTIONS /firstname.lastname@example.org/ 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.
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.
@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
@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";
here (PHP 7.2.18). I didn’t manage to make it return an empty string.
gzencodehave 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.
@synncgw I see, so the server previously sent
Content-Encoding: gzipwithout 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.