Open bash99 opened 6 years ago
@bash99 27401ebe3f2142da6436cae1f16c1f373e9a3f3e is not the latest commit, 05b2092e07f9d10b3803d8fb9775d2f87dc58590 is. Did you try it on both upstream and local? It involves a fix, that might be related to the issue you describe.
I cannot reproduce your issue with the latest build: it works for me. I used the same exact setup as you did with locahost upstreaming proxy on :54086
@sergeyfrolov I'm very sorry for miss a configuration line which proved to be critical.
it's broken with gzip config in upstream
xyz.xyz.info {
forwardproxy {
basicauth aaa aaa
probe_resistance myaaa.local
serve_pac /foraaa.pac
response_timeout 30
dial_timeout 30
}
root /var/www/html
gzip
}
I dug deeper into this issue, but had no success discovering the cause. I suspect it gets compressed twice or Content-Length
is not updated properly somewhere.
@bash99 I will note, however, that the only reason for you to explicitly enable gzip
is to compress your files that you host on xyz.xyz.info
. Forward proxied traffic will be compressed anyway, assuming both client and target support compression.
It appears to me that gzip
writes header (which updates Content-Length
and other things), only if header wasn't written already. Since the header is always written by the forwardproxy, gzip never will. However, apparently, data still gets compressed (potentially for a second time).
@mholt does that sound like a bug in gzip?
I'm not entirely sure, because even if it was a bug, I'm not sure how gzip could change the Content-Length header value after the headers are written. Notice how we just omit that header, here, because of that issue: https://github.com/mholt/caddy/blob/d47b041923daf055bb97c94f29a7f5bf14a4cb2a/caddyhttp/gzip/gzip.go#L114-L119
But does it (re-)compress, when the data was compressed/header was written already? Seems to me like it does (re-)compress, but perhaps shouldn't in either of those cases?
If it's already compressed, then you're right, it shouldn't re-compress, that might be a bug. It'd be the first I've/we've heard of it though :) (Seems a bit unusual.)
@sergeyfrolov Yes, I can live without the gzip config line.
One more thing I can provide is, if I use firefox/chrome to access upstream proxy directly (with gzip config line), I've no problem at all.
1. Is bug reproducible with latest
forwardproxy
build?Yes and I've try build myself, a035ebe works, and 27401eb failed.
2. What are you trying to do?
forward with upstream caddy proxy
3. What is your entire Caddyfile?
upstream setting
local proxy setting
4. How is your client configured?
5. How did you run Caddy? (give the full command and describe the execution environment). If multiple servers are used (for example with
upstream
), describe those as well.just start caddy from command line.
6. Please paste any relevant HTTP request(s) here.
7. What did you expect to see?
download the aaa.txt and print it on console
8. What did you see instead (give full error messages and/or log)?
use strace on both side, I've found upstream caddy actually write the response
and it seems local caddy has also received it
but caddy don't think the request is finished.
9. How can someone who is starting from scratch reproduce the bug as minimally as possible?
use above config.