[master] 477a5dd84 builtin.vcl: Delete Content-Range header where it has no meaning

Nils Goroll nils.goroll at uplex.de
Mon Aug 12 14:08:05 UTC 2024


commit 477a5dd84f727e4a3916295ed58cf3a80f7f7f04
Author: Nils Goroll <nils.goroll at uplex.de>
Date:   Tue Jul 23 10:31:36 2024 +0200

    builtin.vcl: Delete Content-Range header where it has no meaning
    
    Since 4ab110047130e3a89936104d74f4729b650676f9 (see also #3246), we fail backend
    responses with an unexpected Content-Range.
    
    Yet RFC9110 states:
    
            The Content-Range header field has no meaning for status codes that do
            not explicitly describe its semantic.
    
            https://www.rfc-editor.org/rfc/rfc9110.html#section-14.4
    
    The semantic is described for status codes 206 and 416, so the obvious
    implementation change would be for core code to only consider Content-Range for
    these status codes.
    
    But there might be scenarios where a stricter-than-RFC check is intended, so we
    keep that in core code and change builtin.vcl to remove the header where it has
    no semantic.

diff --git a/bin/varnishd/builtin.vcl b/bin/varnishd/builtin.vcl
index 770081366..ed459ce13 100644
--- a/bin/varnishd/builtin.vcl
+++ b/bin/varnishd/builtin.vcl
@@ -210,6 +210,7 @@ sub vcl_backend_response {
 }
 
 sub vcl_builtin_backend_response {
+	call vcl_beresp_range;
 	if (bereq.uncacheable) {
 		return (deliver);
 	}
@@ -245,6 +246,14 @@ sub vcl_beresp_vary {
 	}
 }
 
+sub vcl_beresp_range {
+	if (beresp.status != 206 && beresp.status != 416) {
+		# Content-Range has no meaning for these status codes
+		# Ref: https://www.rfc-editor.org/rfc/rfc9110.html#section-14.4
+		unset beresp.http.Content-Range;
+	}
+}
+
 sub vcl_beresp_hitmiss {
 	set beresp.ttl = 120s;
 	set beresp.uncacheable = true;
diff --git a/bin/varnishtest/tests/c00034.vtc b/bin/varnishtest/tests/c00034.vtc
index 4858d3967..1331c265d 100644
--- a/bin/varnishtest/tests/c00034.vtc
+++ b/bin/varnishtest/tests/c00034.vtc
@@ -273,6 +273,18 @@ varnish v1 -vcl+backend {
 			return (pass);
 		}
 	}
+
+	# skip built-in vcl_beresp_range
+	sub vcl_backend_response {
+		if (bereq.uncacheable) {
+			return (deliver);
+		}
+		call vcl_beresp_stale;
+		call vcl_beresp_cookie;
+		call vcl_beresp_control;
+		call vcl_beresp_vary;
+		return (deliver);
+	}
 }
 
 client c8 {
@@ -326,3 +338,44 @@ client c9 {
 	expect resp.status == 200
 	expect resp.bodylen == 256
 } -run
+
+# built-in vcl has vcl_beresp_range to ignore content-range for responses but
+# 206, 416
+#
+server s1 {
+	rxreq
+	expect req.url == "/?unexpected=content-range"
+	expect req.http.range == <undef>
+	txresp -hdr "content-range: bytes 0-49/100" -bodylen 40
+
+	rxreq
+	expect req.url == "/?unexpected=unsatisfied-range"
+	expect req.http.range == <undef>
+	txresp -hdr "content-range: bytes */100" -bodylen 100
+
+	rxreq
+	expect req.url == "/?invalid=content-range"
+	expect req.http.range == <undef>
+	txresp -hdr "content-range: bytes=0-99/100" -bodylen 100
+
+} -start
+
+varnish v1 -vcl+backend {
+	sub vcl_recv {
+		return (pass);
+	}
+}
+
+client c10 {
+	txreq -url "/?unexpected=content-range"
+	rxresp
+	expect resp.status == 200
+
+	txreq -url "/?unexpected=unsatisfied-range"
+	rxresp
+	expect resp.status == 200
+
+	txreq -url "/?invalid=content-range"
+	rxresp
+	expect resp.status == 200
+} -run


More information about the varnish-commit mailing list