node 14 file url looses host on windows path

[lachrist]

Version

v14.18.2

Platform

Darwin softs-MacBook-Pro.local 19.6.0 Darwin Kernel Version 19.6.0: Thu Sep 16 20:58:47 PDT 2021; root:xnu-6153.141.40.1~1/RELEASE_X86_64 x86_64

Subsystem

No response

What steps will reproduce the bug?

var url = new URL("file://host/path");
console.log(url.host) // logs "host"
url.pathname = "C:/dir";
console.log(url.host) // logs ""

How often does it reproduce? Is there a required condition?

Nope

What is the expected behavior?

Keep the host field of the url intact on modifying the pathname as the spec indicates. FYI node 16 does not have this bug.

What do you see instead?

No response

Additional information

No response

[MoonBall]

@lachrist I test on [email protected] and doesn't reproduce this issues. I think that this issue have fixed.

[Trott]

@lachrist I test on [email protected] and doesn't reproduce this issues. I think that this issue have fixed.

They (@lachrist) did say that it was fixed on 16.x:

FYI node 16 does not have this bug.

So I imagine the question is "will the fix be backported to 14.x?"

[Trott]

I'm guessing the behavior change was in #35477. @watilde

[Trott]

I'm guessing the behavior change was in #35477. @watilde

That is to say: I think #35477 fixed the problem. It's a semver-major pull request, so it landed in 15.0.0 and would not be backported to 14.x and earlier.

(But maybe we can backport a smaller semver-patch fix?)

[Trott]

Hmmm...looks like the previous behavior was spec compliant, and then the spec changed. whatwg/url#302

So we may not want to "fix" previous behavior (in 14.x and 12.x) if it's not a bug under the old spec. We don't want to break people's existing code. (The new behavior was introduced in 15.0.0.)

Thoughts? @nodejs/url

[lachrist]

Thanks for your answers @Trott

So I imagine the question is "will the fix be backported to 14.x?"

That is exactly right.

In my case, the aforementioned difference between 14.x and later versions makes it harder to create portable code. And since there is a spec that the url module should be following it is a bit confusing. Maybe referencing in the doc the version of the spec that the url module is following could already help?

[watilde]

We may not be able to backport my PR #35477 easily since modules system would be affected so that keep the current behaviour of v14 would be better as @Trott mentioned.

So we may not want to "fix" previous behavior (in 14.x and 12.x) if it's not a bug under the old spec. We don't want to break people's existing code. (The new behavior was introduced in 15.0.0.)

+1 to @lachrist's idea:

Maybe referencing in the doc the version of the spec that the url module is following could already help?

[domenic]

WHATWG specs are intentionally unversioned (i.e. "Living Standards") to prevent situations like this and increase interoperability. Referencing any commit (not version) of the spec except the current one is highly discouraged and indicates that Node.js intentionally wants to be buggy software. I would recommend against it.

For more information see FAQs like https://whatwg.org/faq#living-standard and https://github.com/whatwg/html/blob/main/FAQ.md#why-are-there-no-stable-snapshots-or-versions-of-the-standard where we've tried to document this and steer implementations away from such strategies.

[Trott]

@domenic Based on what you've written and the links you've provided, would I be correct to conclude that the options that comply with the spirit of a living standard would be either:

• Backport the "breaking" change to all supported versions of Node.js. (We can do this with Release Team approval, although they have always deferred to the TSC on stuff like this, so it's really TSC approval.)
• Advocate for changes to the spec that would make both behaviors spec-compliant (not a great option in this case, but complies with the spirit)

As far as undesirable options go, in addition to linking to a specific commit of the spect, another undesirable option would be to leave behavior in Node.js 14.x and 12.x (both currently supported versions) as-is?

Do I have that all right?

[domenic]

Backporting would be ideal, indeed. The Living Standards are written under the expectation that they will be implemented by software that updates frequently, like browsers.

[domenic]

Sorry. Let me step back a bit. Upon reflecting for a few minutes, I realized that I am being kind of annoying and inconsiderate.

Node's situation is different than browsers and you all are stuck between some tricky options. I shouldn't speak so confidently about what the right path is. You all know better than me how to balance stability expectations versus correctness expectations, when interacting with bugfixes in your dependencies. While I can talk semi-authoritatively about the intent with respect to browser implementations, Node is different and I shouldn't be so confident I know what is right for you and your users.

If you need to reference the commit snapshots, that might just be a reflection of the fact that it's better for Node to follow a different path than browsers. It's not the end of the world.

[Trott]

I could support trying to generally backport changes like this to supported release lines on a case-by-case basis as long as they are things that only affect highly unusual edge cases, are relatively infrequent, and it won't be too much work for @nodejs/releasers.

[watilde]

I see great discussion in the above, thank you all :) Let me ping @nodejs/modules to kindly ask for your inputs if there is any concern to backport #35477 within module system into v14. My position in general is +1 to backport #35477 if the impact is only on URL. The reason why I +1 is the impact of the changes was not found by citgim when I made PR.
Refs: #35477 (comment)

[TimothyGu]

I also +1 the backport of #35477. Generally we have encountered very few compatibility issues when backporting WHATWG URL changes in the past, especially for edge cases like this one.

[anonrig]

This is not the case anymore. Tested on Node 19.4.0. Closing the issue.

> let a  = new URL('file://host/path')
undefined
> a.pathname = 'C:/dir'
'C:/dir'
> a
URL {
  href: 'file://host/C:/dir',
  origin: 'null',
  protocol: 'file:',
  username: '',
  password: '',
  host: 'host',
  hostname: 'host',
  port: '',
  pathname: '/C:/dir',
  search: '',
  searchParams: URLSearchParams {},
  hash: ''
}

[Trott]

This is not the case anymore. Tested on Node 19.4.0.

As the original reporter noted when opening this issue, it affects 14.x. It was fixed in 16.x (and, by implication, anything after 16.x). 14.x is still affected.

On the one hand, we should probably re-open this because it's still an issue in the release line where it was reported.

On the other hand, at this point it's extremely unlikely to be fixed and will be closed again when 14.x goes out of support in April. So maybe closing as wontfix is the right thing to do.

[anonrig]

I missed that, thanks @Trott

[Trott]

@nodejs/releasers Do you agree that this is unlikely to be fixed in 14.x before the April EOL date and we should probably close this as wontfix?

[bnoordhuis]

Given the thumbs ups I'd say the answer is "not going to get fixed." I'll go ahead and close this.