[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] Output filename not same as from browser save...reason?..

From: Micah Cowan
Subject: Re: [Bug-wget] Output filename not same as from browser save...reason?...bug?
Date: Sun, 25 Jan 2009 18:43:28 -0800
User-agent: Thunderbird (X11/20090105)

Hash: SHA1

Brian wrote:
> Isn't the expected behavior simply that wget behaves as normal but saves
> the file to the extension specified by the mime type in
> content-disposition? Why does this result in performance issues? I have
> encountered this same issue with my web app. You have to specify
> -OfileNameYouExpect, which is what I think users expect wget to do for them.

It's a bit more complicated in wget's case than it is for a simple
browser. In the case of a browser, you've already explicitly chosen that
you want to download this file: and even then, the browser gives you the
specific option (usually) of choosing an alternate name for the file.

In the case of wget, if you're doing timestamping it has to check that
the local file doesn't exist before requesting a full download, which
means it has to perform a HEAD request before each and every file, to
determine what the real name is (from content-disposition) so it knows
which file to check. Similarly for when --no-clobber has been specified,
or we're using accept/reject lists.

The implementor of the feature in its current incarnation chose to be a
little extra-liberal about how the checks are done, and doesn't avoid
issuing the extra HEADs in the majority of cases, even if timestamps,
clobbering, and accept/reject aren't particular issues. We'll get around
to fixing that, but at the moment we have higher priorities.

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
GNU Maintainer: wget, screen, teseq
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


reply via email to

[Prev in Thread] Current Thread [Next in Thread]