[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