I wonder too. Sending HEAD requests is useful tool for forward web proxies to decide whether the content in cache is still enough fresh to serve to the client. So why one want to cache head requests? Does your applications demands too many HEAD requests?
Thank you. Madhava -----Original Message----- From: Sudheer Vinukonda [mailto:[email protected]] Sent: Wednesday, March 30, 2016 9:50 PM To: [email protected] Subject: Re: can't cache head request Agree with what Leif said. Just a couple of more points - - Can you share the use case for caching the HEAD request (just out of curiosity)? - You may write a plugin that either - triggers a GET request in the background on the first HEAD, so that subsequent HEADs are served from cache - or flip the method temporarily from HEAD to GET (I think this should be possible using header_rewrite, but, I haven't tried it :) - worst case, you may need to write a plugin to do this) Regardless, the important thing to note is what Leif mentioned - if you plan on caching HEAD, then your cache key should include the method (this should be possible with a plugin or even the Gancho's cachekey plugin?). Otherwise, there's a danger of serving broken responses to GET requests. Thanks, Sudheer On Wednesday, March 30, 2016 9:01 AM, Leif Hedstrom <[email protected]> wrote: On Mar 30, 2016, at 8:41 AM, Esmq <[email protected]> wrote: > >set proxy.config.http.cache.allow_empty_doc to 1 can't have head request >cached. >and only if object was in cache already, head request will satisfy from cache. > > >can ats cached head request ? > No. Looking at the code, I don’t see a way to force it to do so, and regardless, that would imply that the cache key would have to include the request method as well as the URL (which I’m fairly certain we do not do either). — Leif
