bug#17959: support accessing FTP services via HTTP proxies

[Ivan Shmakov]

        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