From 89e1f00cd540bca54c2cbcb7d9b6cad5e0e3cf34 Mon Sep 17 00:00:00 2001 From: Eric Wong Date: Wed, 5 Jan 2011 10:22:11 -0800 Subject: send proper 416 responses 416 responses without a body should respond with a zero Content-Length and a Content-Range that allows clients to specify a proper range in the future. rfc2616, section 14.16 says: > A server sending a response with status code 416 (Requested > range not satisfiable) SHOULD include a Content-Range field > with a byte-range- resp-spec of "*". The instance-length > specifies the current length of the selected resource. --- t/byte-range-common.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 't') diff --git a/t/byte-range-common.sh b/t/byte-range-common.sh index 514a024..14050cf 100644 --- a/t/byte-range-common.sh +++ b/t/byte-range-common.sh @@ -56,7 +56,9 @@ t_begin "normal full request matches" && { t_begin "crazy offset goes over" && { range_insane=-r$(($random_blob_size * 2))-$(($random_blob_size * 4)) curl -vsS 2>$err $range_insane $url - grep 'HTTP/1\.[01] 416 ' $err || die "expected 416 error" + grep '^< HTTP/1\.[01] 416 ' $err || die "expected 416 error" + grep '^< Content-Range: bytes \*/'$random_blob_size $err || \ + die "expected Content-Range: bytes */SIZE" } t_begin "full request matches with explicit ranges" && { -- cgit v1.2.3-24-ge0c7