Add another point in the "Restrictions" section about how the handling of FTP

URLs will seemingly succeed to read a URL that points to a file whose
permissions you do not have to read.

Backport candidate once everyone agrees with the wording.

diff --git a/Doc/lib/liburllib.tex b/Doc/lib/liburllib.tex
index 47348c1bc6f3ff604f196558862633dc401bc0ac..c411cc86efb565236c9b7f2c5f2c0d8ce0254cf5 100644 (file)
--- a/Doc/lib/liburllib.tex
+++ b/Doc/lib/liburllib.tex
@@ -328,6 +328,23 @@ in the URL; there is currently no easy way to extract it.  If the
 returned data is HTML, you can use the module
 \refmodule{htmllib}\refstmodindex{htmllib} to parse it.
 
+\item
+The code handling the FTP\index{FTP} protocol cannot differentiate between a
+file and a directory and can lead to unexpected behavior when attempting to
+read a URL that points to a file that is not accessible.
+If the URL ends in a \code{/} then it is assumed to be a
+directory and will be handled as such only.  But if an attempt to read a file
+leads to a 550 error (signaling the URL cannot be found or is not accessible,
+often for permission reasons), then the path is treated as a directory in order
+to handle the case of when a directory is specified by a URL but a trailing
+\code{/} is left off.
+This can lead to the apparent successful fetching of a file whose read
+permissions you do not have by still succeeding by returning the directory
+listing for the file from treating it as a directory.
+If more fine-grained control is needed, consider using the \module{ftplib}
+module, subclassing \class{FancyURLOpener}, or changing \var{_urlopener} to
+meet your needs.
+
 \item
 This module does not support the use of proxies which require
 authentication.  This may be implemented in the future.