Hiding 302 replies from clients

[Paul Millar]

Hi all,

I've a question about whether something is possible with Varnish.

Suppose the back-end replies with a 302 return code ("Found" or "Moved 
temporarily").  From a quick test, it seems that Varnish will relay this 302 
reply back to the client.  The client will extract the new URL from the 
"Location" header field and make a second request.

[aside: from a quick test, it seems that varnish always caches the 302 reply 
from the back-end.  It will give the same reply if a client asks for the same 
URL, even when the back-end reply omits any "Cache-Control" or "Expires" 
header.  If this is so then it's a bug.]

What I'd like to happen is that, when receiving a 302 reply from the back-end, 
Varnish would attempt to fetch the data from the redirect URL (given in the 
"Location" header).  Assuming the data is accessible from this URL then the 
client would obtain the data without being redirected.

Is it possible to configure varnish to do this?

In case you're wondering, here's why... Simplifying the setup somewhat, 
consider a distributed http service where a central server that knows about 
all the files but hosts none of the data.  When a client requests a file, the 
central server redirects the client to whichever server is currently hosting 
that file by replying with a 302 reply.  The client can read that file from the 
hosting server with the URL in the "Location" header.

The redirect URL ("Location" header) is a single-use URL: subsequent attempts 
to use that URL will fail.  Requests from the central server will generate a 
new single-use URL.  Since 302 requests are non-cachable by default and 
conforming clients should make subsequent requests to the central server, this 
works.

However, it does make caching awkward.  The stored data does not change, so 
could be cached.  However, if the client sees the redirect then the data would 
be cached against the single-use URLs, and subsequent requests for the same 
data wouldn't use the cached copy.

Cheers,

Paul.