didi/DoKit · warning · ContentLengthException

Received response with 0 content-length header.

Error message

Received response with 0 content-length header.

What it means

NetworkRequestHandler throws ContentLengthException when a response served from the local disk cache reports a 0 content-length header. The code comments note this happens when requests are being replayed and no root cause was found; throwing lets the request pipeline retry, which resolves it. Retrying is explicitly considered safe.

Source

Thrown at Android/dokit/src/main/java/com/didichuxing/doraemonkit/picasso/NetworkRequestHandler.java:67

      return null;
    }

    DokitPicasso.LoadedFrom loadedFrom = response.cached ? DISK : NETWORK;

    Bitmap bitmap = response.getBitmap();
    if (bitmap != null) {
      return new Result(bitmap, loadedFrom);
    }

    InputStream is = response.getInputStream();
    if (is == null) {
      return null;
    }
    // Sometimes response content length is zero when requests are being replayed. Haven't found
    // root cause to this but retrying the request seems safe to do so.
    if (loadedFrom == DISK && response.getContentLength() == 0) {
      Utils.closeQuietly(is);
      throw new ContentLengthException("Received response with 0 content-length header.");
    }
    if (loadedFrom == NETWORK && response.getContentLength() > 0) {
      stats.dispatchDownloadFinished(response.getContentLength());
    }
    return new Result(is, loadedFrom);
  }

  @Override int getRetryCount() {
    return RETRY_COUNT;
  }

  @Override boolean shouldRetry(boolean airplaneMode, NetworkInfo info) {
    return info == null || info.isConnected();
  }

  @Override boolean supportsReplay() {
    return true;
  }

View on GitHub (pinned to 626827cddb)

Solutions

1. Rely on Picasso's built-in retry: NetworkRequestHandler.shouldRetry returns true, so simply letting the request retry usually resolves it
2. Clear the disk cache if the error persists for the same URLs (possible partial cache entry)
3. Upgrade okhttp/picasso alignment if a version mismatch in cache interceptors is suspected

Example fix

// before: caller treats any exception as fatal
try { picasso.load(url).into(view); } catch (Exception e) { /* give up */ }

// after: retry once via Picasso's retrying mechanism or a manual re-load
// (retry is safe per the source comment; ContentLengthException is retriable)

// nothing to validate client-side; the condition comes from the disk cache layer
// mitigations: keep okhttp/picasso versions aligned, clear cache when persistent

// ContentLengthException extends IOException; let Picasso's shouldRetry path retry it.
// For manual loads: retry once before surfacing an error to the UI.
if (exception instanceof ContentLengthException) { retryLoadOnce(); }

When it happens

Trigger: A disk-cache hit (loadedFrom == DISK) whose Response.getContentLength() returns 0; the handler closes the stream and throws so the load can be retried.

Common situations: OkHttp replaying a cached response with a stripped/empty body on flaky networks; conditional-cache revalidation edge cases; cache corruption after an interrupted write. Usually intermittent and self-healing on retry.

Related errors

• uri == null
• path == null
• file == null
• Downloader must not be null.
• Memory cache must not be null.

AI-assisted analysis of didi/DoKit@626827cddb (2026-08-14). Data as JSON: /api/errors/bac16cbaf727654b. Report an issue: GitHub.