[wptserve] Limit number of additional subdomains

[jugglinmike]

[wptserve] Limit number of additional subdomains

Recently, the set of origins reserved by wptserve was increased to
include a combinatoric set of configuration values. This logic used a
"depth" of three, causing the server to reserve subdomains of subdomains
of subdomains (e.g. www.www.www.web-platform.test). For the default
configuration, this produced 312 distinct origins.

The motivating feature request describes a use case for a "depth" of 2
[1]. Re-implement to use that depth, limiting the generated set of
origins to 62. Update the implementation to make this functionality
testable, and update the corresponding tests to verify the intended
behavior.

[1] #8581

[jgraham]

@gsnedders will have an opinion, but to me it seems more useful to have more depth but fewer domains at each depth; realistically there isn't a use case for having 25 subdomains of depth two, or 125 of depth 3. I would be more tempted to limit the number using something like

for i in range(1,6):
    for item in itertools.islice(itertools.product(_subdomains, repeat=i), 5):
        print ".".join(item)

(assuming the subdomains are a list). This does mean you don't get a punycode item at each position (it basically means that you only get www at levels > 1 and each other subdomain at level 1).

[gsnedders]

Note the underlying patch was reverted in #12462. Would need to look up if anyone cared about the IDN mix.

[jugglinmike]

Now that the original change has been reverted, my vote is for a static list derived from the stated needs of test authors. "a subdomain of a subdomain (and another subdomain of the same subdomain)" could be satisfied by a.www.web-platform.test and b.www.web-platform.test. To communicate exclusivity for cookies tests, we could use cookies-a.www.web-platform.test and cookies-b.www.web-platform.test instead.

[jgraham]

I would prefer to avoid churn here (for example: making this work with https requires regenerating certificates) so I would do something we think will likely meet future requirements rather than narrowly scoping the changes to meet only the needs of a specific set of tests.

[jugglinmike]

A narrowly-scoped change will limit unnecessary variation within tests. It's harder to simplify the infrastructure after tests have been written than it is to conservatively introduce features on an as-needed basis. I'm sure you're well aware of this, but we may differ on how much churn we will tolerate in the interest of limiting complexity.

I also need to admit to some bias. I'm working on a successor to w3c-test.org, so my concerns are different than those of typical WPT contributors (who far outnumber me). Additional subdomains increase the complexity of deploying the server publicly, and that makes me more interested in a narrowly-scoped change.

Ideally, the deployment could respond to changes in subdomain requirements automatically. I think this may be possible with the services we've selected. I'm using Amazon Route 53 for DNS, and that supports "*" entries. I'm using Let's Encrypt/Certbot for SSL certificate management, and that has experimental support for wildcard certificates. I haven't proven this out yet, though, and not all configurations may have these options available.

Do you two think "deployability" is a relevant design consideration?

[jgraham]

I get the impression that this PR won't land, but #13272 might. If that's incorrect, please reopen.