On Fri, 27 Jun 2014, Dimitrios Siganos wrote:

> I have an http server which returns the Content-Range: */12345. The libcurl
> Content-Range parser parses the range start offset as 12345 instead of 0 or
> '*'. This causes file corruption if the user asks for resume_from=12345 and
> the server responds with http error 416 and with some HTML payload relating
> to the error. The reason is that we interpret the total file length as a
> start offset which is wrong. This is easily solved by not trying to look for
> the start offset beyond the '/' slash character.

Thanks. You've clearly identified a bug and I filed
https://sourceforge.net/p/curl/bugs/1407/ to track it. But I'm not entirely
happy with this fix as it feels like it gets it right almost by accident.

The Content-Range header is specified here:
http://tools.ietf.org/html/rfc7233#section-4.2

It is quite clear that the "*/[size]" syntax is specifically written to mean
that the requested range was unsatisfied. So I would rather that we explicitly
detect the "*" in there and treat that as offset zero!

Also, I'd love to get at least one test case that verifies that this fix
actually does what it intends to. Any chance you can fix those two issues?

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html