Closed Kukis13 closed 9 months ago
Hey @Kukis13, thanks for raising the issue. Apologies for the late reply.
You'll see this log if the value of a header that's needed by the cache is not a valid HTTP date when it's expected to be so. HTTP dates can come form different places. The stack trace shows that the invalid date comes from the Expires
header. It seems that some servers set the value of this header to -1, 0, or any invalid date when they want the cache to regard the response as already expired, which means they don't want caches to serve them without contacting the server. This is already covered by the spec, section 5.3:
A cache recipient MUST interpret invalid date formats, especially the
value "0", as representing a time in the past (i.e., "already
expired").
Whether the response was saved into cache or not can only be determined by seeing the values of other headers. For instance, the value of the max-age
directive overrides whatever set by Expires
, as per the spec (same section):
If a response includes a Cache-Control field with the max-age
directive (Section 5.2.2.8), a recipient MUST ignore the Expires
field. Likewise, if a response includes the s-maxage directive
([Section 5.2.2.9), a shared cache recipient MUST ignore the Expires
field. In both these cases, the value in Expires is only intended
for recipients that have not yet implemented the Cache-Control field.
BTW, in order to know programmatically whether the response was saved/read into/from cache, you can use an HttpCache.Listener
like so:
var cache = HttpCache.newBuilder()
.cacheOnMemory(8 * 1024)
.listener(new HttpCache.Listener() {
@Override
public void onWriteSuccess(HttpRequest request) {
// Called when the response body is successfully written to cache.
System.out.println("Written to cache: " + request.uri());
}
@Override
public void onResponse(HttpRequest request, CacheAwareResponse<?> response) {
// Called when the response is served. If the status is HIT or CONDITIONAL_HIT then it's been served form cache.
System.out.println(request.uri() + " " + response.cacheStatus());
}
})
.build();
Having said that, it seems that currently Methanol doesn't properly conform to the spec when the Expires
header is invalid, because it assumes that it's just not present in that case, which is not the same thing. I will keep this issue open till this is fixed.
Hi, I use your library exclusively because I need to cache (ideally forever) my HTTP requests. However anytime I hit it any reading from cache ends up with:
Why does it happen? And when it happens does it mean that the request was successfully read from cache or not?