Fix one of those "nothing can possibly go wrong" bugs that are so

typical of "lets just try to get this into the release" features.

The resent addition of experimental Range: header support, broke
a cornercase in normal content delivery.

If an object was delivered from the backend using chunked encoding,
and was larger than the storage segment size (default: 128k) this
bug may bite.

The effect of the bug is that up to storage segment worth of junk
may be appended to the transmitted object.

This is mostly harmless, because the Content-Length header will make
the browser do the right thing, but certain load-balancers will
go cross-eyed and act really weird at the TCP level, spewing
interesting RST packets to the client.

This bug is only in 2.1.1, not in 2.1.0.

Fixes:			#694
Isolated by:		ay
Fool who did this:	phk


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4758 d4fa192b-c00b-0410-8231-f00ffab90ce4

bin/varnishd/cache_response.c

@@ -325,7 +325,7 @@ RES_WriteObj(struct sess *sp)
 		}
 		if (ptr + len > high)
 			/* Chop tail of segment off */
-			len = 1 + high - low;
+			len = 1 + high - ptr;
 
 		ptr += len;
 

bin/varnishtest/tests/r00694.vtc

+# $Id$
+
+test "Wrong calculation of last storage segment length"
+
+server s1 {
+	rxreq
+	send "HTTP/1.1 200 Ok\r\n"
+	send "Transfer-encoding: chunked\r\n"
+	send "\r\n"
+	# This is chunksize (128k) + 2 to force to chunks to be allocated
+	chunkedlen 131074
+} -start
+
+varnish v1 -vcl+backend {
+	sub vcl_deliver {
+		unset resp.http.content-length;
+	}
+} -start
+
+client c1 {
+	txreq -proto HTTP/1.0
+	rxresp
+	expect resp.bodylen == 131074
+} -run