I think the version 2.2.19 behavior is correct. See RFC 2616 section 14.35.1 "Byte Ranges". Request and response sample in each versions. ===== version 2.2.20 GET / HTTP/1.1 Host: localhost Range: bytes=-1 HTTP/1.1 206 Partial Content Server: Apache/2.2.20 (Unix) Accept-Ranges: bytes Content-Length: 2 Content-Range: bytes 0-1/10240 Content-Type: text/html ===== version 2.2.19 GET / HTTP/1.1 Host: localhost Range: bytes=-1 HTTP/1.1 206 Partial Content Server: Apache/2.2.19 (Unix) Accept-Ranges: bytes Content-Length: 1 Content-Range: bytes 10239-10239/10240 Content-Type: text/html ===== Fix patch for version 2.2.20 release. ===== diff -Nur httpd-2.2.20-orig/modules/http/byterange_filter.c httpd-2.2.20/modules/http/byterange_filter.c --- httpd-2.2.20-orig/modules/http/byterange_filter.c 2011-08-30 00:59:39.000000000 +0900 +++ httpd-2.2.20/modules/http/byterange_filter.c 2011-09-01 15:05:44.000000000 +0900 @@ -501,7 +501,7 @@ break; } - if (dash == range) { + if (dash == cur) { /* In the form "-5" */ if (apr_strtoff(&number, dash+1, &errp, 10) || *errp) { break; =====
You are correct. Fixed in trunk as r1163985.
There is one special case here: -0 RFC does not define that case as syntactically invalid. My reading is that it's considered valid but unsatisfiable (If a syntactically valid byte-range-set includes ... at least one suffix-byte-range-spec with a non-zero suffix-length, then the byte-range-set is satisfiable.). The latest httpd behaviour is to handle that as invalid, hence ignore Range header and return 200. That's quite reasonable, given that -0 is not any better than invalid 10-9. Just noting here so it can be decided if it should stay as is or be changed to be more rfc-compliant. Required change seems trivial (allowing number >= 0). And maybe I'm just reading the RFC wrong.
Fixed in 2.2.21
Regarding comment #2, I wonder if it's been overlooked, or whatever the behaviour (invalid vs. unsatisfiable) is for the meaningless case is considered fine. Should I do separate bug for it? Thanks!