Micah Cowan <[EMAIL PROTECTED]> writes:
> Actually, the reason it is not enabled by default is that (1) it is
> broken in some respects that need addressing, and (2) as it is currently
> implemented, it involves a significant amount of extra traffic,
> regardless of whether the remote end actually ends up using
> Content-Disposition somewhere.
I'm curious, why is this the case? I thought the code was refactored
to determine the file name after the headers arrive. It certainly
looks that way by the output it prints:
{mulj}[~]$ wget www.cnn.com
[...]
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `index.html' # not "saving to" only after the HTTP response
Where does the extra traffic come from?
> Note that it is not available at all in any release version of Wget;
> only in the current development versions. We will be releasing Wget 1.11
> very shortly, which will include the --content-disposition
> functionality; however, this functionality is EXPERIMENTAL only. It
> doesn't quite behave properly, and needs some severe adjustments before
> it is appropriate to leave as default.
If it is not ready for general use, we should consider removing it
from NEWS. If not, it should be properly documented in the manual. I
am aware that the NEWS entry claims that the feature is experimental,
but why even mention it if it's not ready for general consumption?
Announcing experimental features in NEWS is a good way to make testers
aware of them during the alpha/beta release cycle, but it should be
avoid in production releases of mature software.
> As to breaking old scripts, I'm not really concerned about that (and
> people who read the NEWS file, as anyone relying on previous
> behaviors for Wget should do, would just need to set
> --no-content-disposition, when the time comes that we enable it by
> default).
Agreed.
