search

web-platform-tests / wpt

Test suites for Web platform specs — including WHATWG, W3C, and others
https://web-platform-tests.org/
Other
4.82k stars 3.02k forks source link

Arbitrary subdomains #13465

Open annevk opened 5 years ago

annevk commented 5 years ago

In order to test what code points are allowed in domain name labels (and how they end up in Host, Origin, and Referrer headers) I need arbitrary subdomains. (See https://github.com/httpwg/http-extensions/issues/702.)

This would also make #4880, #8581, and #11219 easier as we'd simply route all requests.

The flipside is that this would make deployment of wpt more involved as it requires running dnsmasq (or equivalent) plus configuring some OS-level routing rules.

It does seem very important to test this, but I can see an argument for testing this in isolation.

(If https://tools.ietf.org/html/draft-west-let-localhost-be-localhost became a thing however this would be very easy as we could switch to localhost for all things and not even require /etc/hosts manipulation.)

cc @mikewest @mnot

foolip commented 5 years ago

@jugglinmike

jgraham commented 5 years ago

The localhost thing wouldn't help with running this on w3c-test.org or equivalent. Setting up custom DNS in browser CI infrastructure also seems daunting given that typically test jobs don't have root access. Maybe DoH could help here if that gets widespead adoption? I'm not sure.

mikewest commented 5 years ago

With regard to the browser CI infrastructure, I don't think that's actually a challenge. Chromium already generally maps everything under .test to loopback when running in layout test mode, so we're basically already covered if we decided to add arbitrary hosts to WPT.

jgraham commented 5 years ago

I think it solves the problem for Chromium but not for other browsers :) It's probably possible to make development builds of Firefox do something similar, but I'm not sure that there's an equivalent workaround available for e.g. testing stable releases of Safari, or mobile browsers where you actually don't want localhost but the address of the host machine.

mikewest commented 5 years ago

I wasn't at all clear, apologies. In my head, I added a sentence like "Other browsers should be able to do the same without much effort."

But I didn't think about testing against stable releases, and you're entirely correct that that would require more work. We can either put that work on browser vendors (by designing and implementing a webdriver flag for this kind of wildcarding), or put it on folks who host testing infrastructure (e.g. by requiring W3C to add a wildcard DNS record to w3c-test.org).

jugglinmike commented 5 years ago

@foolip mentioned me because I'm maintaining http://web-platform-tests.live, an installation we'd like to replace w3c-test.org. I can speak to some of the deployment concerns, but I'm new to this domain (note the fantastic pun), so please bear with me.

Wikipedia derides wildcard DNS records as underspecified and inconsistently implemented. Does anyone on this thread have experience to know how much of a concern this will be in a practical sense? That article also cites ICANN's "Wildcard Prohibition." Being technically correct probably isn't so important, but I'm wondering if this means that support from hosting providers will dwindle over time.

I also like @annevk's idea of testing this in isolation because that might make it easier to share the tests with non-web-browsers.

mnot commented 5 years ago

There are a lot of moving parts here; not only browsers, but also system resolvers, dns proxies, dns recursives, roots, registrars, web servers, CDNs, etc. all are going to make a difference here.

I.e., even if we determine that all browsers allow a particular character, set of characters or encodings as input (in various places), doesn't mean that it'll be interoperable or even usable on the open Internet.

So I can see a limited, local and controlled test to determine what current browser behaviour is, but as soon as you involve other components, you're going to be seeing a lot of noise.

annevk commented 5 years ago

@jugglinmike I don't think that's a good reason for isolation. For sharing tests we put all the test data in JSON and write some kind of wrapper around that specific to the implementation. That's already possible and done throughout wpt.

domenic commented 4 years ago

Allowing tests to generate an origin used only for that test would help with #20773.

annevk commented 4 years ago

This blocks https://github.com/whatwg/url/issues/390 a bit.

noamr commented 2 years ago

https://github.com/web-platform-tests/rfcs/pull/112 should address this. A Proxy config file (PAC) allows resolution of arbitrary subdomains.

noamr commented 1 year ago

I think this is resolved now, no? We can test arbitrary domains/subdomains with proxy configuration.