Re: metalink support

(moved over from libcurl, since this list is probably more appropriate)

> Am 19.06.2012 18:16, schrieb Tatsuhiro Tsujikawa:
> > On Tue, Jun 19, 2012 at 5:45 AM, Guenter<lists_at_gknw.net> 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:
> >> http://curl.haxx.se/metalink.cgi?curl=win64-ssl-sspi
> >> 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
> filename);
> 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 ...