Closed wadtech closed 8 years ago
Thanks for raising this. The issue was that requests for existing, complete files were still submitting a resume request to the server, starting from the end of the file which is obviously out of range.
HTTP response codes should always be checked by the client code, not grab. The reason for this is that it is not safe for grab to assume that an expected response is definitely 2XX. In this particular case however, the issue was definitely in grab's codebase.
Thanks for fixing so quickly.
If I use grab to download the same file multiple times consecutively, given a server that responds to unsatisfiable range requests with 416 and a response body, I will get a corrupted file on the second attempt.
Using the demo code provided:
and the url
https://s.w.org/screenshots/3.8/colors.png
I get the following output:
Note the difference in calculated content length.
Using
less
to view the end of the file reveals the error body from the later requests:If this is something I should account for in my client code (I'm using the library similarly to the demo) then please could I have some pointers on where to look in the docs? If it's a bug I'm happy to help.
Thanks