As with any kind of response caching, the presumption is that, *if* the Origin included Cache Control headers that permitted Caching of a 400 response, it (the Origin) must know and expect that subsequent requests with matching "cache key" may be served directly from the caches. If the Origin did not want the response to be served from a Cache directly, it should not have indicated that the response was cacheable or should have included enough information to tell the Caches when to revalidate or when not to serve from the Cache directly.
More specifically, if the Origin returned a 400 because (a) the request URL was incorrectly formatted, subsequent requests with the same kind of URL may continue to result in 400 (b) a request header that was inconsistent or invalid, subsequent requests with that specific header may continue to result in 400 etc.. In the first case, caches using request URL as the default cache key require no additional Vary header to serve from the cache, while in the latter case, caches need to be told on which header they may serve from the Cache for subsequent requests. The bottom line, I think is that, I don't specifically see anything different to caching (or not) a 400 response as opposed to a 404, for instance. It's a different matter, if the Origin is broken and one needs to "accommodate" for the brokenness of the Origin. Even in such a case, I'd think the *default* ATS behaviour should not be addressing a "broken" Origin behaviour. - Sudheer > On Nov 9, 2016, at 10:56 AM, Alan Carroll > <solidwallofc...@yahoo-inc.com.INVALID> wrote: > > But that would be very specific to the bad request. Why would it benefit the > next request to be denied with that same response? > > > On Wednesday, November 9, 2016 11:23 AM, Sudheer Vinukonda > <sudheervinuko...@yahoo.com.INVALID> wrote: > > > Generally, I'd think if the Origin responded with Cache-Control headers that > permit caching, it should be cached. > For e.g., for a 400 response, the Origin may include a Cache-Control: Vary > header indicating what parts of the request that it didn't like. > - Sudheer > From: Alan Carroll <solidwallofc...@yahoo-inc.com.INVALID> > To: Dev <dev@trafficserver.apache.org> > Sent: Wednesday, November 9, 2016 8:17 AM > Subject: Don't negative cache 400 responses. > > We are having this problem inside Yahoo! and it seems to me to be wrong to > negative caches a 400 (HTTP_STATUS_BAD_REQUEST) because that is a user agent > / proxy problem, not an origin server problem. It can lead to easy (if > temporary) denial of service by simply sending a bogus request through ATS. > I'd like to clip that status out of is_negative_caching_appropriate. > > > > >
