You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@shindig.apache.org by "Richard Wallace (JIRA)" <ji...@apache.org> on 2009/09/09 23:55:57 UTC
[jira] Created: (SHINDIG-1168) Caching error responses too
aggressively
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.
[jira] Commented: (SHINDIG-1168) Caching error responses too
aggressively
Posted by "Paul Lindner (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (SHINDIG-1168) Caching error responses too
aggressively
Posted by "Richard Wallace (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773979#action_12773979 ]
Richard Wallace commented on SHINDIG-1168:
------------------------------------------
The problem we ran into was "400 Bad Request" responses being cached. But even 404s shouldn't be cached if the server tells you not to. If they tell you not to and then you wind up pounding them with requests, that's really their problem to fix not yours.
> 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.
[jira] Commented: (SHINDIG-1168) Caching error responses too
aggressively
Posted by "Paul Lindner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773977#action_12773977 ]
Paul Lindner commented on SHINDIG-1168:
---------------------------------------
There are some sites that set cache-control headers to no-cache on 404s, very annoying.
I'm considering adding support for the Retry-After: header, which might be one way around your problem... Normally that's used with 503 and 3xx responses.
> 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.