On Mon, Jul 28, 2008 at 10:42 AM, Brian Eaton <[EMAIL PROTECTED]> wrote:
> Kevin sent a bunch of good comments about shindig r678354, I'm > responding to them in individual notes because they touch on several > different areas. > > Comment: this change broke negative caching. > > The old code ignored cache-control headers on non-200 responses. I > discovered this because it was causing problems for some OAuth > protocol flows, and attempted to fiox it. It sounds like the behavior > was as designed. > > This is an interesting challenge, because OAuth enabled servers return > 401 responses with no-cache headers, and they expect the no-cache > header to be respected. For example, a client may request an OAuth > enabled resource, and the server will return a 401 indicating that the > authorization for the resource is no longer valid. The client is > supposed to get the user's permission, and then try again. If the 401 > response is cached, this will fail. > > There are a few possibilities to fix this. > > - disable negative caching just for the OAuthFetcher > Kind of ugly, but would certainly work. The OAuthFetcher code > didn't use to cache at all, but I really want the performance > improvements caching offers. Adding special cases would be a > reasonable compromise. > > - disable negative caching for 401 and 403 responses > Less ugly than the previous solution, and probably reasonably accurate. A whitelist of HTTP responses that are likely to be returned by a functioning server is fine. The entire 4xx range isn't suitable though (in particular because a lot of web servers return 404 when they're malfunctioning). Given the small number of HTTP response codes, it shouldn't be too hard to add a map of all potential response codes and the behavior for each. > > > - respect cache-control headers always > Might cause the performance problems that negative caching is supposed to > fix. > > Any comments on which solution is preferable? > > Cheers, > Brian >
