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.

1 files changed, 17 insertions, 0 deletions

diff --git a/Doc/lib/liburllib.tex b/Doc/lib/liburllib.tex
index 47348c1..c411cc8 100644
--- a/Doc/lib/liburllib.tex
+++ b/Doc/lib/liburllib.tex
@@ -329,6 +329,23 @@ 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.