yeah I think you have got it, tho I'm not saying its wget fault I will try and find a download so you can verify the issue, I have had at least 2 in recent months..
yeah I do realise the problem atm is with a known length file - the examples I will provide are also known length however it may take some time to track down the downloads - I just lost 1Tb drive with url references and everything I have ever downloaded.. so it may take some time - I have had one within last 30 days tho - might be able to find it thru browser history note that I never did debug output for any of these servers - just observed responses to normal wget use, did various tests to confirm it was reproduced and not user or filesystem issue On Wed, Mar 21, 2012 at 3:44 AM, Micah Cowan <[email protected]> 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. > > Still, none of this is likely to be DJ's problem, since he's doing this > for a known-length file on a heavily-used server. > > -mjc
