[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] http server responding with 416 but file was not transfer

From: Tim Rühsen
Subject: Re: [Bug-wget] http server responding with 416 but file was not transferred completely
Date: Thu, 14 Sep 2017 10:12:10 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

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 ==
> 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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]