Re: [Bug-wget] [PATCH] New option: --rename-output: modify output filename with perl

[Micah Cowan]

On Thu, Aug 01, 2013 at 01:24:12PM +0200, Giuseppe Scrivano wrote:
> Tim Ruehsen <address@hidden> writes:
> 
> > That is basically a good idea.
> >
> > Do you have in mind to keep as close to the standard CGI environment 
> > variables 
> > as possible ? Or do you think of the CGI environment principle ?
> > If the latter, we should use an own namespace and let environment variables 
> > start with WGET_.
> 
> In any case it won't be CGI so we have the freedom to do whatever we
> like :-)
> 
> I think it is good to make a difference between HTTP headers and other
> variables, generated by wget, that we would like to pass to the external
> process.

How would you handle FTP urls, though?

In Niwt's case (doesn't currently support non-HTTP/S), the design intent
is to translate all protocols to HTTP (since that's what the discrete
Niwt processes speak amongst themselves), possibly with extended headers
(to represent such things as file permissions or whatnot). A sort of
"HTTP proxy for all other protocols", implemented as a process within
the application, as opposed to an actual network server.

Perhaps FTP URLs could be distinguished by SERVER_PROTOCOL being "ftp",
in which situations Wget might not offer any of the other usual CGI
headers, or perhaps a custom, minimal translation of some FTP
information into CGI variables...?

(God, I hate FTP... damn LIST output was never intended to be parsed
by automata, support for the newer parsable commands is too
unreliable, and the whole control/data thing is a vestige of the days
before the TCP protocol was even properly ironed out. I want to see it
die so bad.)

-mjc