Micah Cowan <[EMAIL PROTECTED]> writes:
>> 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?
>
> Your example above doesn't set --content-disposition;
I'm aware of that, but the above example was supposed to point out the
refactoring that has already taken place, regardless of whether
--content-disposition is specified. As shown above, Wget always waits
for the headers before determining the file name. If that is the
case, it would appear that no additional traffic is needed to get
Content-Disposition, Wget simply needs to use the information already
received.
> As to why this is the case, I believe it was so that we could
> properly handle accepts/rejects,
Issuing another request seems to be the wrong way to go about it, but
I haven't thought about it hard enough, so I could be missing a lot of
subtleties.
>> 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.
>
> It's pretty much "good enough"; it's not where I want it, but it
> _is_ usable. The extra traffic is really the main reason I don't
> want it on-by-default.
It should IMHO be documented, then. Even if it's documented as
experimental.
