Why 204 are not cached by OkHttp? - http

Question

Looking at the code in CacheInterceptor I see that response with the code 204 are not cached. Yet I believe 204 are cacheable as discussed here
We use 204 as a response to GET don't indicate an empty response and just recently noticed those are not cached.

Answer 1

There are a number of reasons why.
Why does the implementation behave like this?
Technically, 204s are skipped because the intercept method will only cache responses if promisesBody returns true:
if (response.promisesBody() && CacheStrategy.isCacheable(response, networkRequest)) {
// Offer this request to the cache.
As you might expect, promisesBody returns false for 204 responses, unless they have a Content-length header, or chunked transfer encoding:
/**
* Returns true if the response headers and status indicate that this response has a (possibly
* 0-length) body. See RFC 7231.
*/
...
val responseCode = code
if ((responseCode < HTTP_CONTINUE || responseCode >= 200) &&
responseCode != HTTP_NO_CONTENT &&
responseCode != HTTP_NOT_MODIFIED) {
return true
}
// If the Content-Length or Transfer-Encoding headers disagree with the response code, the
// response is malformed. For best compatibility, we honor the headers.
if (headersContentLength() != -1L ||
"chunked".equals(header("Transfer-Encoding"), ignoreCase = true)) {
return true
}
return false
Why was this design used?
To justify this decision, it's possible that OkHttp's general use case for a cache is to save re-sending large payloads, rather than keeping round-trips to the absolute minimum. In addition, 204 is valid as a response to a GET, but more often used as a response to a POST; it's possible that the design reflects knowledge of this heuristic.
Why hasn't this changed?
Looking through relevant issues, there is one related to changing the default behaviour for certain status codes: OkHttp cache-by-default status codes out of date:
The spec wants these:
200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501
which resulted in a test:
assertCached(true, 204);
However, due to the configuration of the mock server, the response used to test is:
HTTP/1.1 204 OK
...
Content-Length: 0
with exactly the unnecessary Content-Length that its own detection requires, and which a valid response should not include.
tl;dr
It's a bug, which nobody who's run into this case has reported.

Answer 2

A 204 is returned when there is no content - "The server successfully processed the request and is not returning any content."
Therefore there is no data to cache if using the code to spec. If you are returning content/data than a 200 would be more appropriate.