On Thu, Aug 01, 2013 at 01:24:12PM +0200, Giuseppe Scrivano wrote: > Tim Ruehsen <[email protected]> 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
