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 <>
In-reply-to <>
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
"".  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 * modules demonstrate,
and it would break compatibility with people's existing directory
structures.  And with ospath->URL transation elsewhere, I'm sure.
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