Zitat von Micah Cowan <[EMAIL PROTECTED]>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Micah Cowan wrote:
> > Jochen Roderburg wrote:
> >> Unfortunately, however, a new regression crept in:
> >> In the case timestamping=on, content-disposition=off, no local file
> present it
> >> does now no HEAD (correctly), but two (!!) GETS and transfers the file two
> >> times.
> >
> > Ha! Okay, gotta get that one fixed...
>
> That should now be fixed.
>
> It's hard to be confident I'm not introducing more issues, with the
> state of http.c being what it is. So please beat on it! :)

This time it survived the beating  ;-)
Seems that we are finally converging. The double GET is gone, and my other test
cases still work as expected, including the -c variants.

> One issue I'm still aware of is that, if -c and -e
> contentdisposition=yes are specified for a file already fully
> downloaded, HEAD will be sent for the contentdisposition, and yet a GET
> will still be sent to fetch the remainder of the -c (resulting in a 416
> Requested Range Not Satisfiable). Ideally, Wget should be smart enough
> to see from the HEAD that the Content-Length already matches the file's
> size, even though -c no longer requires a HEAD (again). We _got_ one, we
> should put it to good use.
>
> However, I'm not worried about addressing this before 1.11 releases;
> it's a minor complaint, and with content-disposition's current
> implementation, users are already going to be expecting an extra HEAD
> round-trip in the general case; what's a few extra?

Agreed. I can confirm this behaviour, too. And I would also consider this a
minor issue, at least the result is correct.

I have also not made many tests where content-disposition is really used for the
filename. Those few "real-live" cases that I have at hand do not send any
special headers like timestamnps and filelengths with it. At least the local
filename is set correctly and is correctly renamed if it exists.

Best regards and thanks again for the repair of all the issues that I found,

Jochen Roderburg

Reply via email to