[
https://issues.apache.org/jira/browse/SHINDIG-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774730#action_12774730
]
Paul Lindner commented on SHINDIG-1168:
---------------------------------------
true, but the act of pounding is expensive for the container too.
> 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.
