Are we just talking about proxy.config.http.negative_caching_enabled https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html#proxy-config-http-negative-caching-enabled
If so, then the doc implies that it only affects responses without cacheable Cache-control directives. mile On Wed, Nov 9, 2016 at 11:55 AM, Sudheer Vinukonda <sudheervinuko...@yahoo.com.invalid> wrote: > 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. >> >> >> >> >> >
