Hallvard B Furuseth <h.b.furus...@usit.uio.no> added the comment: 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. ---------- status: pending -> open _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10231> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
