Author hfuru
Recipients hfuru, jerith, martin.panter, orsenthil, vstinner
Date 2017-11-26.05:16:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <5dc4ac29-d8f2-2af7-a5ec-32c40894aa4d@mail.uio.no>
In-reply-to <1511668788.14.0.213398074469.issue10231@psf.upfronthosting.co.za>
Content
On 26/11/17 04:59, Martin Panter wrote:
> That leaves the fourth complaint, which I don’t understand: ‘translate_path() does not handle initial "."/".." on non-Posix systems’.
>
> As far as I know, in 2010 (and still in 2017) the only non-Posix system Python supported was Windows. But Windows has os.curdir = "." and os.pardir = "..", just like Posix.

os.macpath has ":" and "::".

I don't remember if that's what I was thinking though.  Maybe just
"non-posixpath.py".  A generic problem - you have to think about
each os.<osname>path implementation to see if the translate_path()
is valid.  If you someday add support for another OS, that can
break a working translate_path().  My proposed code would fix that,
at least for that particular code.

> There is a quirk where requests like “GET .” and “GET ../path” will retain the dots after passing through “posixpath.normpath”. If there was a platform where a single or double dot was a legal file or directory name, the server will access the corresponding file or directory in these cases. But this does not seem like a problem.

More generally, translate_path() ought to escape characters and
character combinations which have special meaning in the filesystem.
But that can be hairy, as the *url2path.py modules demonstrate,
and it would break compatibility with people's existing directory
structures.  And with ospath->URL transation elsewhere, I'm sure.
History
Date User Action Args
2017-11-26 05:16:29hfurusetrecipients: + hfuru, orsenthil, vstinner, jerith, martin.panter
2017-11-26 05:16:29hfurulinkissue10231 messages
2017-11-26 05:16:28hfurucreate