mirror of https://github.com/python/cpython
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:
parent
12ac3e1f49
commit
71868e74d6
|
@ -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.
|
||||
|
|
Loading…
Reference in New Issue