Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

URL.pathname getter for file URLs produces odd result on Windows #103

Closed
dd8 opened this issue Mar 21, 2016 · 4 comments

Comments

@dd8
Copy link

commented Mar 21, 2016

The getter for URL.pathname always prefixes the pathname with /
https://url.spec.whatwg.org/#dom-url-pathname

That produces odd results in Windows:

parser.href = "file:///C:/Folder/File4.txt"
parser.pathname returns "/C:/Folder/File4.txt"

On Mac/*nix platforms parser.pathname returns a valid OS pathname. On Windows the returned pathname doesn't appear to be a valid OS pathname:
https://msdn.microsoft.com/en-gb/library/windows/desktop/aa365247%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

Looks like URL standard behaviour matches Chrome/Firefox but not IE11 where .pathname returns "C:/Folder/File4.txt".

@annevk

This comment has been minimized.

Copy link
Member

commented Mar 22, 2016

Nice nickname.

Do you happen to know what Edge does here?

@dd8

This comment has been minimized.

Copy link
Author

commented Mar 22, 2016

IE11: "C:/Folder/File4.txt"
Edge: "/C:/Folder/File4.txt"
Chrome 49: "/C:/Folder/File4.txt"
FF 44: "/C:/Folder/File4.txt"
Safari 9:.0.3: "/C:/Folder/File4.txt"

Thinking about it a bit more I'm not convinced parser.pathname is always a valid OS pathname on Mac/*nix either when special filename characters (e.g. $ or *) or unicode sequences are present in the URL.

There are use cases where paths represented as file URLs need turned into local OS paths (e.g. for FileAPI and server-side JS).

Does the URL interface need another property/method to handle this? .NET has URI.LocalPath for this purpose; Cocoa has NSURL.path which can be passed to other Cocoa file APIs.

Seems like there should be an API for this somewhere (even if it's not in the URL interface) since there's a long history of security issues caused by path parsing vulnerabilities.

@annevk

This comment has been minimized.

Copy link
Member

commented Dec 19, 2016

Apologies for the belated reply. It seems like all browsers agree here. Do you have a case where the output of the URL parser is not suitable somehow? It deals with Unicode and most "special" code points.

It's also a little unclear where something like LocalPath would be used, even if we figure out what it should do, which is a little unclear to me.

@annevk

This comment has been minimized.

Copy link
Member

commented Jan 3, 2017

I'm going to close this. Happy to continue the discussion or reopen when provided with some new data.

@annevk annevk closed this Jan 3, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants
You can’t perform that action at this time.