Re: [Bug-wget] Problem using GNU Wget 1.11.4 Windows version

[Micah Cowan]

On 03/20/2012 07:44 AM, Micah Cowan wrote:
> On 03/20/2012 02:01 AM, Paul Wratt wrote:
>> so let me re-itterate others on the list:
>> It is possible for wget to get a true response to 206, but fail to
>> "seek to partial start", rather starting from 0. if file is of unknown
>> length it may be added to end of current file
> 
> I'm having a little trouble understanding exactly what you're saying.
> 
> Is it that, in response to wget's request for ranged content, some
> servers send back a 206, ranged response, but for a range of "0-",
> instead of what wget requested? I did not know this. I had thought that
> would be illegal, but I can't find language in the spec to that effect.
> 
> I'm not sure, but I think wget may assume that 206 responses match the
> range that was requested, without checking. If that's the case, then its
> clearly broken behavior, given what you say above.

So, I checked, and at least _looking_ at the source code, it does look
like wget validates 206 responses, in that it makes sure the start
position is the same one it asked for, or else is zero. Anything else,
and wget closes the connection to the server.

Wget never ever seeks in the file (with the exception that fseeko may be
used to determine the existing file's length, and the file is then
closed afterwards). It opens files in append mode, and skips content
from the server until we've received up to the current file size (which
is a bit unsafe if the content is dynamically-generated, but it's been
that way for a long while now...).

It'd be worth finding out if the servers in question are sending
erroneous Content-Range information (happens from time to time), or if
there's a flaw somewhere in wget's verification of that information.

-mjc