bumptech/glide · warning · HttpException

Failed to get a response message

Error message

Failed to get a response message

What it means

When the HTTP response has a non-OK, non-redirect status code (e.g., 404, 500), HttpUrlFetcher attempts to include the server's response message via urlConnection.getResponseMessage(). If that call throws an IOException (response message unavailable or unreadable), the secondary exception 'Failed to get a response message' wraps it, still carrying the original status code. This is a secondary failure: the real problem is the original HTTP error status.

Source

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

        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;
  }

  private HttpURLConnection buildAndConfigureConnection(URL url, Map<String, String> headers)
      throws HttpException {
    HttpURLConnection urlConnection;

View on GitHub (pinned to eb14a895d8)

Solutions

  1. The underlying issue is the HTTP error status code; check getStatusCode() on the caught HttpException
  2. Fix the server to return proper error responses with complete headers
  3. Integrate OkHttp for more robust HTTP response parsing
  4. Handle the HttpException in RequestListener and display an appropriate fallback

Example fix

// before
Glide.with(context).load(url).into(imageView);
// after — inspect status code and handle
Glide.with(context)
  .load(url)
  .listener(new RequestListener<Drawable>() {
    @Override public boolean onLoadFailed(GlideException e, Object m, Target<Drawable> t, boolean i) {
      for (Throwable cause : e.getRootCauses()) {
        if (cause instanceof HttpException) {
          Log.w(TAG, "HTTP error, status: " + ((HttpException) cause).getStatusCode());
        }
      }
      return false;
    }
    @Override public boolean onResourceReady(Drawable r, Object m, Target<Drawable> t, DataSource d, boolean i) { return false; }
  })
  .error(R.drawable.placeholder)
  .into(imageView);
Defensive patterns

Strategy: try-catch

Try / catch

Glide.with(context)
  .load(url)
  .error(R.drawable.placeholder)
  .listener(new RequestListener<Drawable>() {
    @Override public boolean onLoadFailed(GlideException e, Object model, Target<Drawable> target, boolean isFirstResource) {
      for (Throwable cause : e.getRootCauses()) {
        if (cause instanceof HttpException) {
          int statusCode = ((HttpException) cause).getStatusCode();
          // The real issue is the HTTP error status; 'Failed to get a response message' is secondary
          Log.w(TAG, "HTTP error " + statusCode + " for " + model);
        }
      }
      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: Server returns a 4xx/5xx error and then closes the connection before the response message can be read. The HttpURLConnection implementation cannot extract the reason phrase from the response. Connection drops after the status line but before the full headers.

Common situations: Servers that return an error status and immediately close the socket. Aggressive load balancers that reset connections on error. Android's default HttpURLConnection behaving inconsistently across OEM implementations.

Related errors


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