-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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 formatting in Node v7 cause problems for npm
#9521
Comments
Thanks for the use-case @iarna @nodejs/ctc since we approved this we ought to consider the impact and whether and how we want to apply mitigation in this case. I see a few ways forward:
|
@iarna Just to make sure I'm understanding: npm can and will work around this, so even if we update the docs and that's it, things will be OK with npm (assuming people upgrade npm). In other words, you are informing us of a use case that we seem to have failed to consider and we should make a decision as to whether or not we should accommodate that use case. But either way, npm will be fine. Or am I misunderstanding? |
I'm OK with any of the options @rvagg listed, but (assuming @iarna's answer to my question in the preceding comment is "yes, that is correct") I'd prefer the first one: retain the current behavior and update the docs. And my second choice is the last one (basically, keep the current behavior generally, but add relative paths as a possibility even though relative paths are not permitted in file urls according to spec). But I can see reasons to be for and against each of the possibilities. And I would (of course) feel differently if this were causing widespread breakage in the ecosystem. If that were the case, I'd probably be all for reverting. |
Actually...I just did a test in a browser, and Chrome, at least, understands relative file paths. Given that "do what the browser does" seems to be the general philosophy for |
While I would generally prefer |
I gotta say, while I understand that there are times when a strictly conformant URL implementation is useful, I have found url's easy going nature to be very useful, in both formatting and parsing, it allows it to be used for all kinds of non-internet standard encoding of url-like data, as npm found. |
At the risk of getting a little too far off topic: I mostly agree, but...there are things lurking... Well, here's an example: Given a FQDN with one component longer than the officially-allowed 63 characters, url.parse() will truncate it to 63 characters (which is acceptable IMO) and decide that the leftover part should be pushed over to the path (which is a problem IMO). Behold: > url.parse('http://www.ThisIsAnAbsurdlyLongHostNameButSurelyNoneOfThisShouldEndUpAsPartOfThePathBecauseWhoCouldPossiblyWantThatAMIRITE.com/CorrectPathBeginning')
Url {
protocol: 'http:',
slashes: true,
auth: null,
host: 'www.thisisanabsurdlylonghostnamebutsurelynoneofthisshouldendupaspar',
port: null,
hostname: 'www.thisisanabsurdlylonghostnamebutsurelynoneofthisshouldendupaspar',
hash: null,
search: null,
query: null,
pathname: '/tOfThePathBecauseWhoCouldPossiblyWantThatAMIRITE.com/CorrectPathBeginning',
path: '/tOfThePathBecauseWhoCouldPossiblyWantThatAMIRITE.com/CorrectPathBeginning',
href: 'http://www.thisisanabsurdlylonghostnamebutsurelynoneofthisshouldendupaspar/tOfThePathBecauseWhoCouldPossiblyWantThatAMIRITE.com/CorrectPathBeginning' }
> Maybe I just have failed to think of an appropriate use case (a 63-character TLD maybe?), but I cannot imagine a situation where the above behavior is desirable. It's easy to think of situations where it leads to bugs. (Basically: Every situation where it might happen.) And I would not be surprised to find that it has the potential for security issues in the right context, although I may lack the creativity to contrive a reasonable example of that myself. In any event, I think we should do what browsers do, which appears to be to not bother validating the char length of components for the FQDN. Garbage in/garbage out, but at least make it sensible garbage that clearly maps to the input. But that's not what's being discussed here. Just a long aside. Thanks for indulging me. (If that topic is of interest, it's being discussed in #9292.) |
Yes, that's right. |
@jasnell It's not |
Looking at the docs right now, I don't think this is a doc omission (although the docs could be more clear). For
That's not exactly the clearest prose expression of all time. But it does say that if the (FWIW, the word So, unless I'm missing something, I think we're covered in the docs if it is determined that sticking with the current behavior is the most desirable course of action. |
(I am going to file a PR to reword it for clarity, though.) |
PR-URL: nodejs#9731 Ref: nodejs#9521 Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
We shipped our own change for this in npm@4.1.0 which I'll be downstreaming to you all this Thursday, Dec 22nd. (Well, 4.1.1 actually, but yeah.) |
This issue has been inactive for sufficiently long that it seems like perhaps it should be closed. Feel free to re-open (or leave a comment requesting that it be re-opened) if you disagree. I'm just tidying up and not acting on a super-strong opinion or anything like that. |
IMPACT: Before I get into the specifics, I want to be clear about what the impact is for
npm
. It's actually pretty limited. As best as we can tell this only impacts when saving a file-type specifier to apackage.json
withnpm
, not when installing from one. As such, it can be worked around by editing thepackage.json
.#7234 introduced a change to how
url.format
printed invalidfile:
type URLs. Specifically if someone gave it the invalidfile:/absolute/path/to/file.txt
it would translate that into the validfile:///absolute/path/to/file.txt
. Previously invalid URLs were left unaltered.npm
's use offile
URLs are usually to point at relative paths, which isn't somethingfile
URLs are really setup to support. The waynpm
does this is tackfile:
on the front, sonpm -i -S ./foo/
becomesfile:foo
andnpm -i -S ../foo
becomesfile:../foo
.As of v7, those become
file://foo
andfile://../foo
respectively. The first being a reference to/
on thefoo
host, and the latter being a reference to/foo
on the..
host.Ok, so Node v7 is making legacy URLs "healthy" where it didn't used to and that bit our particular use case. We can update
npm
to work around that, but there is an additional wrinkle…We don't actually call
url.format('file:foo')
. What we call is:It'd be legit to call this a doc bug and update there, imo, though ignoring properties in the object form feels odd to me. Either way, we'll be updating our code to not rely on
url.format
.The text was updated successfully, but these errors were encountered: