-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Jochen Roderburg wrote:
> Zitat von Micah Cowan <[EMAIL PROTECTED]>:

>> 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  ;-)

Yaaaaay!!!!!! :D

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

And I expect there are probably several bugs lurking here (which is why
I've designated it as "experimental"). After the 1.11 release I want to
revisit that section, and look more closely at what happens if we get a
Content-Disposition at the last minute, especially if it specifies a
local file name that we are rejecting. I'd prefer that it not use HEAD
at all for that, as I expect Content-Disposition is rare enough that it
doesn't justify issuing HEAD just to see if its present; and in any case
it probably frequently isn't sent with HEAD responses, but only for GET.

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHElVE7M8hyUobTrERCOG5AJ9xsAPlFyhXXC28E5TeqnoKXWuLPACbBAFN
SfRAf4ZfMFwvYXDKlcDV3dA=
=ZHVD
-----END PGP SIGNATURE-----

Reply via email to