cURL / Mailing Lists / curl-library / Single Mail


Re: metalink support

From: Guenter <>
Date: Tue, 19 Jun 2012 18:46:44 +0200

Am 19.06.2012 18:16, schrieb Tatsuhiro Tsujikawa:
> On Tue, Jun 19, 2012 at 5:45 AM, Guenter<> wrote:
>> Hi all,
>> I did build curl with metalink support, but a test on NetWare failed due to
>> illegal filename; I tested a link from the curl download page:
>> this results in the metalink file 'metalink.cgi?curl=win64-ssl-sspi' which
>> is an illegal one since '?' is not allowed on NetWare, and neither on
>> Windows; so we need to think about what we do here: just cut off the
>> filename string beginning with the '?' (simplest) or replace all possible
>> illegal filename characters with an underscore?
>> Or, maybe even store it as a temp file, and remove it afterwards if the
>> metalink download finished and checksum check was successful?
> Another solution is use -o option and specify safe name.
> Since metalink enabled curl parses metalink file based on the
> content-type the remote server returned, file name does not need to be
> remote name. I'm sorry if I missed the point..
ah, ok, I used -O so it was named after the url (though anyway I thought
that some time back - before metalink support - we discussed this issue
and agreed that we cut off the url beginning with '?' for using as
but then question is: why do we need an download option at all (-o | -O)
? Whouldnt it make sense to support metalink download also if no
download option is provided but the server headers identify as metalink
in content-type? Then the metalink data could be stored into a temporary
file, and deleted after successful download and checksum verification ...
currently the metalink data is only printed to stdout if no -o | -O is
given instead of being parsed ...

BTW. Daniel: your blog about metalink support was somewhat misleading
because your sample:
curl --metalink [URL]
is wrong; for an URL you dont need the --metalink switch but only for a
local file ...


List admin:
Received on 2012-06-19