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.
This commit is contained in:
Brett Cannon 2004-07-13 00:48:42 +00:00
parent 12ac3e1f49
commit 71868e74d6
1 changed files with 17 additions and 0 deletions

View File

@ -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.