2010/2/18 Pierre-Yves Ritschard <p...@spootnik.org>
> > 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.
>
>
I'm glad to hear this :)
