-
Notifications
You must be signed in to change notification settings - Fork 141
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
Changes to file URL path normalization #544
Changes to file URL path normalization #544
Conversation
The build fails because bikeshed is down at the moment. |
Thanks a lot @alwinb for your work on this! One thing I failed to check in on is bugs. I'll file one for Node.js and rust-url. I don't think Chrome/Firefox is needed as they have bigger issues. Should there be one for Safari? |
Yes, there are corner cases where Safari is different. My understanding is this happens only when a host-less url is parsed against a base url. Quote:
From #405 (comment). Note that this is not drive letter specific behaviour. And, thanks, it's the first time I did something like this so it's nice to see it work out! |
Thanks, I filed https://bugs.webkit.org/show_bug.cgi?id=217170. (You're free to do this yourself next time if you want, https://github.com/whatwg/meta/blob/master/MAINTAINERS.md has some instructions.) |
…ation proposal, a=testonly Automatic update from web-platform-tests Changes URL tests for file path normalization proposal For whatwg/url#544. -- wpt-commits: 050308a616a8388f1ad5d6e87eac0270fd35023f wpt-pr: 25716
There is a concern here for Node.js modules that There are also existing examples of Are these properties hard constraints on the change here? The alternative in the Node.js modules system might be to throw for these |
In general the mapping from URLs to files on the filesystem will not be 1:1. E.g. on Windows This generally comes down to the question as to how module maps are to be keyed: by "request URL" (~ module specifier) or "response URL" (~file inode). |
It is true that how a filesystem handles a file URL is outside of the scope of the URL specification. We support both case-sensitive and non-case-sensitive filesystems, which causes strange problems like domenic said. |
For NodeJS, another thing to maybe take into account is code portability. I think that e.g. |
Various JS platforms and tools rely on file URLs now as their module registry identifier to align with browsers and support HTTPs loading alongside files. Node.js and Deno are two. More build tools may follow suit here as well. Yes this is very much about edge cases. A better example might be something like: export async function loadFileSystemPath (path) {
return await import('file:///' + path);
} or any other registry full URL construction. Case sensitivity is a problem Node.js had before the shift to URLs so is probably best treated out of scope certainly. Might it be possible to more easily support these base separator renormalization cases here? It not, Node.js will likely implement some extra renormalization / validations before landing these changes. But it's a class of bugs for server JS platforms going forward so if there's ways to make it easier that could be useful. Otherwise these separator normalization issues could cause these edge case bugs in environments that are not aware of the pitfalls. |
Also note these cases may not even be that rare. Here is the list of tests that needed to be changed in Node.js core for this PR to land - nodejs/node#35429 (comment). |
I think handling this in a normalization step is the right thing to do. The URL parser can produce many URLs that map to the same file; it's the function of systems built on top of the URL parser (such as HTTP servers, module registries, or standalone helpers like |
I am not sure if the example is to be taken literally, but just in case, |
@alwinb url.pathToFileURL exists already. I'm not entirely sure the recommendation here as the test for policies at least is failing with the existing implementation of that. We could update that helper but is the expectation that all comparisons of these leading |
@alwinb the specific issue is that the path being concatenated will be either |
URL comparison can be done using ===. File comparison cannot be done using === comparison on URLs. Whether you want to use URL comparison, or file comparison, for your module specifiers, is up to you. |
@domenic so, to clarify, if |
Import maps (and the web in general) do not have a concept of files, only URLs. I don't know how Node, or "scoping mechanisms", want to deal with files. (So in particular, the "are expected to" is not a valid premise on the web.) |
@domenic in both Node.js and Deno, |
@domenic https://fetch.spec.whatwg.org/ is vague on the behavior of "file" URLs and I'm more just trying to ensure we don't have some problem with forwards compatibility compared to current behavior for what URLs are assigned when you use files (such as ). It seems like prohibiting fetch operations from succeeding for more than 2 |
Right, the translation from URLs to files on the filesystem is not specified (certainly not by Fetch), and not really part of the web. It's browser- and OS-specific. I'm not sure how to give compatibility guidance about that subject.
Yes, for example if someone did |
don't forget there are normalization issues with Unicode non-ascii file names. |
Not if you have the case sensitive flag enabled on the directory in which the file is located:
I have it enabled for a good chunk of my file system. |
Refs: whatwg/url#544 Refs: web-platform-tests/wpt#25716 PR-URL: #35477 Fixes: #35429 Reviewed-By: Guy Bedford <guybedford@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com> Reviewed-By: Bradley Farias <bradley.meck@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com>
…ation proposal, a=testonly Automatic update from web-platform-tests Changes URL tests for file path normalization proposal For whatwg/url#544. -- wpt-commits: 050308a616a8388f1ad5d6e87eac0270fd35023f wpt-pr: 25716
Refs: whatwg/url#544 Refs: web-platform-tests/wpt#25716 PR-URL: nodejs#35477 Fixes: nodejs#35429 Reviewed-By: Guy Bedford <guybedford@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com> Reviewed-By: Bradley Farias <bradley.meck@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com>
Changes to file URL path normalization as proposed in #405.
Summary:
Applicable only to file URLs:
localhost
then it is set to the empty string.Intends to close #405 and #302.
Preview | Diff