bug#17959: support accessing FTP services via HTTP proxies

[Ivan Shmakov <ivan@siamics.net>]

	Alternatively, one may question of why the guard was necessary
	in the code in the first place?

	Scanning through the url*.el code, I’ve found that there’re
	certain differences in handling URIs.  Namely, while some URI
	scheme handlers (like http:) retrieve a document when a URI is
	referenced, others (like irc:) instead call some “third-party”
	code, and there’s also a group (news:, file:, ftp:) of handlers
	which follow either of these ways depending on specific
	conditions.

	And in the case of FTP, – the condition upon which no document
	is retrieved is: the URI in question refers to a directory.

	The differences are due to the fact that while some URIs (say,
	news:877fxricgb.fsf_-_@violet.siamics.net or
	http://example.com/) refer to certain /documents,/ there’re also
	URIs which are unlikely to ever denote anything like that (think
	of, say, geo:20,15.)

	Thus, my suggestion would be to:

	• allow the caller of the url*.el facilities to explicitly state
	  whether it’s interested in a document to be returned, in some
	  code to be called, or either;

	• in the ‘url-file’ function, – return a document of some form
	  (possibly the unprocessed output of the respective FTP
	  command) when given a URI which refers to a directory, – if so
	  is the preference of the caller;

	• (not directly related to this bug) adjust ‘url-news’ (and
	  possibly others) behavior similarly, perhaps going as far as
	  allowing the caller to specify its preferences regarding the
	  representation for such a document, – in the spirit of the
	  HTTP Accept: header.

	I guess all of the above warrant separate bug reports, which I
	hope to file shortly.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A