bumptech/glide · error · HttpException

Http request failed

Error message

Http request failed

What it means

After the connection is established, HttpUrlFetcher reads the HTTP response code via getResponseCode(). If that call throws an IOException (so no status code can be determined), the helper returns INVALID_STATUS_CODE (-1). When the main redirect-handling logic encounters this sentinel value, it throws new HttpException(statusCode), which the HttpException constructor renders as 'Http request failed, status code: -1'. This indicates the server connection was made but no usable HTTP response was received.

Source

Thrown at library/src/main/java/com/bumptech/glide/load/data/HttpUrlFetcher.java:125

    if (isHttpOk(statusCode)) {
      return getStreamForSuccessfulRequest(urlConnection);
    } else if (isHttpRedirect(statusCode)) {
      String redirectUrlString = urlConnection.getHeaderField(REDIRECT_HEADER_FIELD);
      if (TextUtils.isEmpty(redirectUrlString)) {
        throw new HttpException("Received empty or null redirect url", statusCode);
      }
      URL redirectUrl;
      try {
        redirectUrl = new URL(url, redirectUrlString);
      } catch (MalformedURLException e) {
        throw new HttpException("Bad redirect url: " + redirectUrlString, statusCode, e);
      }
      // Closing the stream specifically is required to avoid leaking ResponseBodys in addition
      // to disconnecting the url connection below. See #2352.
      cleanup();
      return loadDataWithRedirects(redirectUrl, redirects + 1, url, headers);
    } else if (statusCode == INVALID_STATUS_CODE) {
      throw new HttpException(statusCode);
    } else {
      try {
        throw new HttpException(urlConnection.getResponseMessage(), statusCode);
      } catch (IOException e) {
        throw new HttpException("Failed to get a response message", statusCode, e);
      }
    }
  }

  private static int getHttpStatusCodeOrInvalid(HttpURLConnection urlConnection) {
    try {
      return urlConnection.getResponseCode();
    } catch (IOException e) {
      if (Log.isLoggable(TAG, Log.DEBUG)) {
        Log.d(TAG, "Failed to get a response code", e);
      }
    }
    return INVALID_STATUS_CODE;

View on GitHub (pinned to eb14a895d8)

Solutions

  1. Retry the request; transient connection drops often succeed on retry
  2. Verify the server is healthy and responding to normal browser requests
  3. Integrate OkHttp with Glide for better connection handling and retry policies
  4. Handle the failure gracefully with .error() and show a placeholder

Example fix

// before
Glide.with(context).load(url).into(imageView);
// after — add error handling and retry via listener
Glide.with(context)
  .load(url)
  .error(R.drawable.placeholder)
  .into(imageView);
Defensive patterns

Strategy: retry

Validate before calling

// Verify the server responds before loading
private boolean isServerReachable(String url) {
  try {
    HttpURLConnection conn = (HttpURLConnection) new URL(url).openConnection();
    conn.setConnectTimeout(5000);
    conn.connect();
    int code = conn.getResponseCode();
    conn.disconnect();
    return code > 0; // INVALID_STATUS_CODE is -1
  } catch (IOException e) {
    return false;
  }
}

Try / catch

Glide.with(context)
  .load(url)
  .error(R.drawable.placeholder)
  .listener(new RequestListener<Drawable>() {
    int retryCount = 0;
    @Override public boolean onLoadFailed(GlideException e, Object model, Target<Drawable> target, boolean isFirstResource) {
      for (Throwable cause : e.getRootCauses()) {
        if (cause instanceof HttpException && ((HttpException) cause).getStatusCode() == -1) {
          if (retryCount < 2) { retryCount++; return true; } // retry
        }
      }
      return false;
    }
    @Override public boolean onResourceReady(Drawable r, Object m, Target<Drawable> t, DataSource d, boolean i) { return false; }
  })
  .into(imageView);

Prevention

When it happens

Trigger: The server accepted the TCP connection but closed it before sending a complete HTTP response. getResponseCode() throws IOException due to a protocol error or premature connection close. A proxy or intermediary resets the connection mid-response.

Common situations: Overloaded servers that drop connections under pressure. Unstable mobile data connections that drop mid-transfer. Proxy servers with aggressive timeouts. HTTP/HTTPS mismatch causing protocol errors.

Related errors


AI-assisted analysis of bumptech/glide@eb14a895d8 (2026-08-14). Data as JSON: /api/errors/43a256c40259ada1. Report an issue: GitHub.