On 09/14/2017 09:53 AM, Josef Moellers wrote: > Hi, > > We have seen (at least) one server who has > Accept-Ranges: bytes > in his header but, upon receiving a request with > Range: bytes=23068672- > responds with > HTTP/1.1 416 Requested Range Not Satisfiable > although the file was not transferred completely! > > wget then claims that > The file is already fully retrieved; nothing to do. > > E.g. > run > wget https://downloads.dell.com/FOLDER02721216M/1/SUU_14.12.200.69.ISO > the, after a couple of MB, abort the transfer and then continue the > download: > wget --continue > https://downloads.dell.com/FOLDER02721216M/1/SUU_14.12.200.69.ISO > > Maybe the check in src/http.c: > 3821 if (statcode == HTTP_STATUS_RANGE_NOT_SATISFIABLE > 3822 || (!opt.timestamping && hs->restval > 0 && statcode == > HTTP_STATUS_OK > 3823 && contrange == 0 && contlen >= 0 && hs->restval >= contlen)) > > should be changed and any HTTP_STATUS_RANGE_NOT_SATISFIABLE with an > incomplete file should show something like > > "download continue failed, file incomplete"
Well, that would be ok for this special server. Normally 416 together with a server timestamp matching the file's timestamp means that the file is complete (as far as the client can judge from HTTP). IMO, if the server is broken (or misbehaves) then the server should be repaired. Except it is a very common misbehavior. In which case we could consider a work-around on the client side. With Best Regards, Tim
signature.asc
Description: OpenPGP digital signature
