2

I am downloading a file with okhttp and things work fine - now I want to show the progress and hit a road-bump. The returned content-length is -1. It comes back correctly from the server:

⋊> ~ curl -i http://ipfs.io/ipfs/QmRMHb4Vhv8LtYqw8RkDgkdZYxJHfrfFeQaHbNUqJYmdF2                                        13:38:11
HTTP/1.1 200 OK
Date: Tue, 14 Jun 2016 11:38:16 GMT
Content-Type: application/octet-stream
Content-Length: 27865948

I traced the problem down to OkHeaders.java here:

 public static long contentLength(Headers headers) {
    return stringToLong(headers.get("Content-Length"));
 }

I see all the other headers here in headers - but not Content-Length - so headers.get("Content-Length") returns null. Anyone has a clue how this can get lost?

Interestingly if I change the url to "http://google.com" I get a content-length from okhttp - but with curl both look same Content-Length wise - this really confuses me

Update: it seems to correlate with he size of the file. If I use smaller content from the same server I get a Content-Length with okhttp. The problem only happens when the file is big

ligi
  • 39,001
  • 44
  • 144
  • 244

1 Answers1

6

It looks like above a certain size the server uses chunked encoding and you won't get a content length.

HTTP/1.1 200 OK
Date: Tue, 14 Jun 2016 14:30:07 GMT
Content-Type: application/octet-stream
Transfer-Encoding: chunked
Yuri Schimke
  • 12,435
  • 3
  • 35
  • 69
  • Thanks - but why do I see the content-length with curl? – ligi Jun 14 '16 at 18:14
  • 1
    I suspect because okhttp automatically advertises gzip support, I get teh same behaviour with curl with `curl -i -H "Accept-Encoding: gzip" -s http://ipfs.io/ipfs/QmRMHb4Vhv8LtYqw8RkDgkdZYxJHfrfFeQaHbNUqJYmdF2` – Yuri Schimke Jun 15 '16 at 14:03