new URL('file://').origin is 'null'

[caub]

var {URL}=require('url'); new URL('file://').origin is 'null' on Node.js.

This result is not helpful/practical, I think it should be 'file://' like in browser (Chrome 58/Linux), or an empty string

edit: indeed Firefox outputs 'null' too

[annevk]

You'll need to elaborate more on why it's not useful. Opaque origins always serialize to "null".

[annevk]

(And I don't think what you state goes for each browser by the way.)

[TimothyGu]

In Chrome, all non-special schemes and file scheme URLs that I can find have origins of scheme + ://

[annevk]

Filed https://bugs.chromium.org/p/chromium/issues/detail?id=722089 though I think it might be a duplicate.

[caub]

Thanks, I updated the first message. I don't agree a lot with this 'null', it's like losing information, but I'll do with it

[rmisev]

Yes duplicate, someone filed this bug a year ago: https://bugs.chromium.org/p/chromium/issues/detail?id=608606

[felixfbecker]

Am I the only one who thinks it sounds terrible, like a bug, to have any segment be serialized to the literal string "null"? Literally any other option seems preferrable, e.g. the empty string or literal null. Do we really want JS devs to have to write code like if (!url.origin || url.origin === 'null')?
This really breaks the mental model of the properties of the URL being "segments" of the input URL that are stitched back together when calling url.toString().

[TimothyGu]

Unlike other URL attributes, origin is specifically designed not to be a verbatim URL fragment. Consider new URL('https://user:pass@host.com/').origin, IIRC it returns 'https://host.com' which is assembled from nonlinear chunks of the URL.

URL origins serve a very specific purpose in the web security model and one shouldn’t think of it as a part of the URL in general. This is also why origin is a read-only attribute.

Do we really want JS devs to have to write code like if (!url.origin || url.origin === 'null')?

I don’t remember a case where url.origin could ever be falsey.

[felixfbecker]

Thanks for the explanation. Still, why string "null"? Does the string "null" have any meaning in the web security model? For example, if I wanted to check if two URLs are considered same-origin, it seems like I now can't just do url.origin === url.origin, since two URLs with "null" origin should probably not be considered same-origin, right? But it's not obvious that that is a valid case that needs to be handled. A type string | null would make it a lot clearer that a URL may not have an origin and that that is a case that needs to be accounted for.

[annevk]

Yes it has a meaning, see https://html.spec.whatwg.org/#ascii-serialisation-of-an-origin. You'll also find it with CORS, postMessage(), etc.

[annevk]

Also, origin isn't really a segment of a URL, it's computed from the segments and is basically an object. It's unfortunate that it's serialization looks like a URL though, I think that was a mistake in retrospect.

[felixfbecker]

Got it, makes sense to align with the HTML spec then (even though it still seems weird to me)