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