hostinfo should expose NOTSAMESITE_HOST

[bzbarsky]

Right now it doesn't seem to.

@jgraham

[annevk]

FWIW, you should feel free to modify common/get-host-info.sub.js to expose new constants.

[jugglinmike]

Since the value is derived from the "alternate_host" configuration, I think it would be more clear to expose it as ALTERNATE_HOST. @bzbarsky based on your motivating comment in gh-13823, it doesn't seem like the name NOTSAMESITE_HOST is specifically important. Would you be satisfied if it were exposed as ALTERNATE_HOST instead?

[bzbarsky]

The important part from my point of view is that it is always "not same site" with the main host, in the sense of having a different TLD+1. I wanted to make that somewhat clear in the naming so someone doesn't accidentally change it to no longer have that property.

I don't particularly care what the name is, as long as we can't accidentally break the above invariant (e.g. if we have a test to ensure that it holds).

[annevk]

We should not expose it under a different name as there's already tests all over using HTTP_NOTSAMESITE_ORIGIN and HTTPS_NOTSAMESITE_ORIGIN. Furthermore, "same site" is the established terminology, see https://url.spec.whatwg.org/#host-same-site for instance.

An alternative name that would be acceptable if someone wanted to rename things would be "CROSSSITE_HOST", but that doesn't seem worth the effort.

(Personally I always use those the origin constants by the way, but I haven't really played with things where I need a "raw" host recently I suppose.)

[annevk]

@bzbarsky btw, I'd be happy to fix this if this is blocking something for you, but I also don't really see why you couldn't just add a test where you need it and expose it at the same time.

[bzbarsky]

This is not blocking me per se; it's needed to address my review comments at #13823 (comment)

[jugglinmike]

I don't particularly care what the name is, as long as we can't accidentally break the above invariant (e.g. if we have a test to ensure that it holds).

As it happens, we just yesterday started talking about testing the files in common/.

However, the test for this file could only really assert that the JavaScript value matches the server configuration value. In order to provide the kind of assurance you'd like, we'll need to extend the server. It should verifies that the operator has not misconfigured the server by selecting an "alternate" host which is identical or otherwise related to the "primary" host.

That's an important invariant regardless of if/how we expose the value in get-host-info.sub.js. See gh-17943

We should not expose it under a different name as there's already tests all over using HTTP_NOTSAMESITE_ORIGIN and HTTPS_NOTSAMESITE_ORIGIN. Furthermore, "same site" is the established terminology, see https://url.spec.whatwg.org/#host-same-site for instance.

Thanks for that context, @annevk. The conventions on the web and in the tests trump the convention in the WPT infrastructure.

There might still be an opportunity to improve consistency, though. Maybe the alternate_host configuration should instead be notsamesite_host. I've opened gh-17942 to learn why that's a bad idea :P