> This appears to be due to the format of the string being passed to
> strtonum(). ap_strtol() was tolerant of it. It's being passed the
> string from the Range: header.
>
> For example, the following valid request (taken directly from sniffing a
> wget session).
>
> GET /testfile HTTP/1.0
> Range: bytes=300417024-
>
> This ends up following the code path of the first strtonum() call around
> line 159 in http_protocol.c in the parse_byterange() function. The
> string passed to strtonum to convert (r->range) not only contains the
> number from the header, but the trailing dash ("300417024-"), which
> strtonum does not like. As strtonum fails, the start offset is set to
> 0.
>
> This bug should be present on a 64-bit arch as well.
>
>
Hi,
I broke it when unbreaking support for large files in Content-Length (which
would otherwise report 0). I'll have a diff ready soon which fixes that.
- pyr.
