Caching error responses too aggressively
----------------------------------------
Key: SHINDIG-1168
URL: https://issues.apache.org/jira/browse/SHINDIG-1168
Project: Shindig
Issue Type: Bug
Components: Java
Affects Versions: 1.0
Reporter: Richard Wallace
We were trying to use a web service that returns a 400 response code if there
is something wrong with the request, like the user didn't fill out all the
required information. These responses were getting cached by Shindig, so when
the user went to fix the request it didn't matter, they got the same error
response out of the Shindig cache. This caching occurs in spite of the fact
that a 'Cache-Control: no-cache, no-store' header is present in the response
headers.
After doing some digging I found this bit of code
{code}
public long getCacheExpiration() {
// We intentionally ignore cache-control headers for most HTTP error
responses, because if
// we don't we end up hammering sites that have gone down with lots of
requests. Certain classes
// of client errors (authentication) have more severe behavioral
implications if we cache them.
if (isError() && !NEGATIVE_CACHING_EXEMPT_STATUS.contains(httpStatusCode)) {
return date + negativeCacheTtl;
}
{code}
With isError() defined as
{code}
public boolean isError() {
return httpStatusCode >= 400;
}
{code}
The comment in the getCacheExperation() method is reasonable. We don't want to
hammer a server if it is down. The problem is in the isError() method. An
internal server error is indicated by a 5xx response code. The responses in
the 4xx range indicate an error with the request. These should not ignore the
Cache-Control heading as outside factors could make the request valid the next
time it is performed - for instance, a user requests details about another
user, but that user is currently in the process of being created. The current
request will fail with a 404, but if they resend the request a few seconds
later when the user has been created they should receive the user details.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
