Cache a Redirect Response from reverse_proxy
rhullah opened this issue · 9 comments
I have an external service behind a reverse proxy that returns a 302 Redirect response. I'd like to be able to change the response into a 301 and to cache the redirect response so that it can be served from cache if re-requested w/in the configured TTL.
In my attempts to do this, I can get the response to change to a 301 response, but it always misses the cache with a header of: Cache-Status: Souin; fwd=uri-miss; detail=UPSTREAM-ERROR-OR-EMPTY-RESPONSE; key=GET-.... Is this possible, and if it is how should I configure this type of behavior?
Hello @rhullah I think that's a little bug one the codebase, we should store the redirect response 3xx status code but according to your feedback it doesn't. We will fix that on the next release!
Thank you for the confirmation. I look forward to the next release.
@darkweak I saw the release go out, v0.12.0, and immediately tried it. Unfortunately I'm still getting the same response as in the original post. I've created a bare bones Caddyfile to replicate the issue. When making a request to http://localhost:8080/redirect, I do get a 301 response with the expected Location header. But it always hits the upstream and doesn't cache it's response.
How can I rewrite the response to be a 301 and cache it so the upstream isn't hit every time?
{
auto_https off
order cache before rewrite
order replace after encode
log {
level debug
format console
}
cache {
nuts {
path /tmp/cache
}
}
}
:8080 {
log
cache {
mode bypass
ttl 2h
}
handle_path /redirect {
rewrite * /redirect-to?url=https://domain.com/dest&status_code=302
reverse_proxy https://httpbin.org {
header_up Host {upstream_hostport}
@redirect_resp {
status 302
header Location https://domain.com/*
}
handle_response @redirect_resp {
@location vars_regexp location {rp.header.Location} https://domain\.com/(.*)
# Not sure if this is needed
header Cache-Control "public, max-age=86400, s-maxage=3600"
redir @location https://new.domain.com/{re.location.1} permanent
}
}
}
}
@rhullah the fix is ready on the Souin repository. You can try it now using xcaddy build --with github.com/darkweak/souin/plugins/caddy@c159776e17fdbbf952b8fb4eb9d997918916360e --with github.com/darkweak/souin@c159776e17fdbbf952b8fb4eb9d997918916360e. Thank you for your feedback.
Yes, that works! Will this be in a upcoming release?
Yes, I plan to release on the Souin repository this evening and once done release on the cache-handler. It will include the fix for #72.
Excellent, thank you for your work!