Add infrastructure for testing origin policy

[domenic]

This adds 99 new subdomains for testing origin policy on, without interfering with other tests. It also configures /.well-known/origin-policy to use a Python script handler, instead of a static file handler, to allow varying responses. Closes #20773.

RFC: web-platform-tests/rfcs#44

[jgraham]

This kind of change requires an RFC since it affects integrators.

[domenic]

RFC made: web-platform-tests/rfcs#44

[jgraham]

Thanks

[domenic]

I'll rebase this in the hopes that maybe the CI will start being green...

[jgraham]

It looks like there's a meaningful failure in the unitests:

=================================== FAILURES ===================================
___________________________ test_config_json_length ____________________________
    def test_config_json_length():
        # we serialize the config as JSON for pytestrunner and put it in an env
        # variable, which on Windows must have a length <= 0x7FFF (int16)
        with ConfigBuilder() as c:
            data = json.dumps(c.as_dict())
>       assert len(data) <= 0x7FFF
E       assert 42392 <= 32767
E        +  where 42392 = len('{"ports": {"https": [8443], "ws": [55777], "h2": [9000], "wss": [48573], "http": [8000, 38419]}, "not_domains": {"": ...w1.www2", "op9", "op8", "op3", "op2", "op1", "op7", "op6", "op5", "op4"], "doc_root": "/home/test/web-platform-tests"}')

Also I think we need to regenerate the certificate so that the domains work over https. I do not at this moment remember the right way to do that, but I'll try to.

[domenic]

Oh dang, thanks, I never know when the CI actually has errors versus sporadic failures.

I'm not sure how to fix that test... it seems like this legitimately causes a config to exceed a limit. I'll poke around, but ideas would also be welcome.

[jgraham]

186d18f has docs on how to regenerate the certs.

The length limit here seems to be a windows limitation with environment variables. I guess we could do something mad, like allow the value to be spread over multiple environment variables and piece them back together. I don't know if there's a more sane suggestion.

[stephenmcgruer]

What's that line from BSG? "All this has happened before, and all this will happen again"?

#12461 is the last time this happened. We tried to add ~300 subdomains, and hit the same environment variable problem. At the time, the fix was to just add less.

We seem to dump the config as JSON in tools/wptrunner/wptrunner/executors/pytestrunner/runner.py, as 'WD_SERVER_CONFIG', and read it in webdriver/tests/support/fixtures.py. So any splitting up of the config would have to happen there, albeit that would be a bit of an ugly hack.

That said, https://devblogs.microsoft.com/oldnewthing/?p=15083 implies that the entire block of env variables has a shared limit, so that may not even help.

Backing up a bit however, perhaps we can just drop some of the bigger bits of data when setting WD_SERVER_CONFIG? If this is only used for webdriver tests (ohhh thats what the WD stands for), does webdriver need the expanded list of subdomains?

[domenic]

Backing up a bit however, perhaps we can just drop some of the bigger bits of data when setting WD_SERVER_CONFIG? If this is only used for webdriver tests (ohhh thats what the WD stands for), does webdriver need the expanded list of subdomains?

This is worth trying. I don't currently have any plans to use web driver stuff in origin policy tests, so hopefully it'll be OK.

Thanks for the pointer to the code; that's invaluable information for trying to make this work.

[domenic]

All checks have passed, woohoo!! Ready for review... I imagine my Python could probably use some critiquing.

[jgraham]

Missing colon at the end of this line is causing CI failures.

[Hexcles]

Woohoo! Thanks for following through with it, Domenic!