Make URL's origin getter return null for file URLs

[annevk]

While we don't (want to) govern (yet) if one file URL can fetch another, we can at least govern that the origins file URLs hand out always serialize to "null".

That is, I would make the getter explicitly check if URL's scheme is "file" and if so, return "null". No need to go through all the trouble of defining a file URL origin I think as navigating to file URLs isn't defined.

This affects Safari and Chrome, neither of which return "null" yet for any non-special URLs as far as I can tell.

cc @achristensen07 @mikewest

[annevk]

Anyone thoughts on this? Or are we ready to give file: URLs always an opaque origin? That would also work for me.

[annevk]

Hey @johnathan79717, I noticed web-platform-tests/wpt#36158 which seems to be doing what this issue wants. That seems like a good change, but we should reflect it in the specification if we're going to change the tests.

In particular making the API always return "null" and leaving the underlying concept as-is for now is I think what you are pursuing?

[johnathan79717]

Yes, I wanted to do that but has gotten some pushback on the chromium CL https://chromium-review.googlesource.com/c/chromium/src/+/3734856?tab=comments

So I think either we give file: URLs an opaque origin, or we keep it an exercise for the readers in the spec but explicitly say that file URLs should serialize to "null". If the spec says so, then it may be easier to persuade Chromium reviewers.

[annevk]

@domenic thoughts on making the getter return "null" but keeping the concept an exercise for now? (Changing the concept seems like a longer-term project although maybe browsers are slowly getting there.)

[domenic]

I'm very pessimistic about browsers getting there. The amount of anger we get any time file: URLs get less access to new features than the actual web is high (e.g. whatwg/html#8121), and actively taking away the ability to fetch() other file: content seems unlikely to go well.

Anyway, I'm ambivalent the proposal at hand. I like the idea of getting at least surface-level interop. I think I would slightly prefer picking some other representative value (e.g. Chromium's "file://") for file URL origins, to represent "here be dragons", and leaving "null" for actually-opaque origins that have well-defined semantics.

[annevk]

I'd rather not introduce a novel origin value. Remember that web content cannot observe the specialness of file: URLs. Only when you navigate to a file: URL you might be able to "appreciate" its rather unique origin behavior. However, I think we should optimize for websites playing with file: URLs and give the same kind of answer they would get for unrecognized schemes.