On 14.09.2017 10:12, Tim Rühsen wrote: > 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.
OK, so I'll have a go at it. Looks simple enough (famous last words ;-) ) Josef
