Gzipped content via proxy upstream
larskluge opened this issue · 6 comments
1. What version of Caddy are you running (caddy -version
)?
0.9.5
2. What are you trying to do?
Does the proxy directive work together with the filter plugin?
I setup Caddy as a proxy and have to rewrite some html content coming back from the upstream server. The filter plugin sounds like being able to rewrite content, but it seems to not kick in with the proxy. Is this possible somehow, or am I using it incorrectly?
3. What is your entire Caddyfile?
:1234 {
filter rule {
content_type text/html.*
search_pattern Foo
replacement Bar
}
proxy / http://www.foo.com {
header_upstream Host www.foo.com
}
}
4. How did you run Caddy (give the full command and describe the execution environment)?
./caddy
(custom version w/ filter plugin included)
5. Please paste any relevant HTTP request(s) here.
6. What did you expect to see?
Bar
7. What did you see instead (give full error messages and/or log)?
Foo
8. How can someone who is starting from scratch reproduce the bug as minimally as possible?
Use Caddyfile from above, and start a caddy server w/ filter plugin.
Originally posted at Caddy, asked to move it here. caddyserver/caddy#1579
Thanks!
You might want to try
proxy / http://www.foo.com {
header_upstream Host www.foo.com
header_upstream Accept-Encoding identity
}
to turn off gzip encoding from the upstream server, then the filter can see the plain text.
That works for the example above, thanks. Unfortunately the upstream I am using (and have no control over) does not listen to the header provided and continues to send gzipped content.
Is there any way to use this plugin with gzipped content from an upstream?
Thanks!
Hey! Unfortunately not currently. This will mean that the plugin has to decode gzip and encode it (afterwards) again. I have to think about if this is feasible and also performant enough but I got your point.
I hear you, thanks for diving into this—would be extremely helpful for me!