[Varnish] #1627: Response where you have do_gzip and do_stream enabled return a wrong content-length to HTTP/1.0 clients
Varnish
varnish-bugs at varnish-cache.org
Thu Nov 13 15:12:35 CET 2014
#1627: Response where you have do_gzip and do_stream enabled return a wrong
content-length to HTTP/1.0 clients
-------------------+--------------------
Reporter: tnt | Type: defect
Status: new | Priority: normal
Milestone: | Component: build
Version: 3.0.6 | Severity: normal
Keywords: |
-------------------+--------------------
During a streaming requests, if varnish gzip the object itself, the final
content-length is unknown. Usually this yields a transfer-encoding chunked
response and it works out. But if the client is HTTP/1.0, it will actually
try to use a content-length and serve a bad one (the one of the
uncompressed object).
See the attached patch for the proposed fix.
Basically in stream_start, instead of replacing the content-length is
res_mode != CHUNKED, I always remove it, and only re-add the correct one
only if RES_LEN is the mode. For HTTP 1.0, RES_EOF will be the one chosen
and so no content-length will be present at all.
The minimal VCL I use to test this :
{{{
backend i_test {
.host = "87.98.160.55";
.port = "80";
}
sub vcl_recv {
set req.backend = i_test;
return (pass);
}
sub vcl_pass {
# Prevent backend from gzipping ...
# (that's not in prod, but in prod my backend can't gzip while
# the http server I use as backend for testing can gzip so
# I prevent it to using this)
remove bereq.http.Accept-Encoding;
}
sub vcl_fetch {
set beresp.do_stream = true;
set beresp.do_gzip = true;
}
}}}
--
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1627>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator
More information about the varnish-bugs
mailing list