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. - 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
