Bug 219642 – Support overriding address space for specific IP addresses in test environments

• Status: NEW
• Component: Tools / Tests

[Titouan Rigoudy]

There is no good way to write Web Platform Tests for the CORS-RFC1918 specification [1] without additional support from browsers. This has been discussed in the WPT repo [2], which led me to write an RFC [3].

The gist of the RFC is this: browsers need additional configuration surfaces to override the address space [4] of specific IP addresses, so as to simulate the behavior under test. For example, we would like to test that requests to public IP addresses are unaffected, but there is no way to make requests to e.g. https://example.org from a test runner. Instead, we would like to tell the browser: "please consider 127.0.100.1 to be public" and then make requests against this IP address, which loops back to the WPT server. This override mechanism can take the shape of command-line flags, or preferences, or any mechanism deemed most apt by WebKit developers.

Since the bulk of the implementation work for this RFC rests with browser developers, the WPT maintainers would like input from them, hence this bug.

Does the idea outlined above (and explored in more detail in [3]) sound reasonable?

[1] https://wicg.github.io/cors-rfc1918/
[2] https://github.com/web-platform-tests/wpt/issues/26166
[3] https://github.com/web-platform-tests/rfcs/pull/72
[4] https://wicg.github.io/cors-rfc1918/#address-space

[Anne van Kesteren]

Sam, Youenn, you might be able to give some input here.

[Radar WebKit Bug Importer]

<rdar://problem/72340759>

[youenn fablet]

It seems what you are asking is an override mechanism for private/local URLs to be considered public.
That seems ok (the reverse of allowing public URLS to be treated as private would probably not be great).
I guess this could be built in platform agnostic code, 
I would guess that network stacks would provide the actual value and platform agnostic code could override it to become public.

Since we are talking WPT, I guess that it would end up being a WebDriver API.
We could probably start with a WTR internals API at first in WebKit.

[Titouan Rigoudy]

I agree with your first paragraph.

As to the second part: I asked around and there seems to be little appetite for this in WebDriver, since the intended audience is mostly browser developers wishing to test their implementations rather than website developers wishing to test their websites.

[youenn fablet]

(In reply to Titouan Rigoudy from comment #4)
> I agree with your first paragraph.
> 
> As to the second part: I asked around and there seems to be little appetite
> for this in WebDriver, since the intended audience is mostly browser
> developers wishing to test their implementations rather than website
> developers wishing to test their websites.

Ok, but WPT would probably still like to run the tests on Safari and not WebKitTestRunner.

[Titouan Rigoudy]

Oh, sure! WPT will want to run tests under Safari for sure. Did I file this bug in the wrong place? I am quite unfamiliar with terminology and process around here :)

[youenn fablet]

(In reply to Titouan Rigoudy from comment #6)
> Oh, sure! WPT will want to run tests under Safari for sure. Did I file this
> bug in the wrong place? I am quite unfamiliar with terminology and process
> around here :)

I think we can keep track of both pieces of work, WebKit and Safari, from this bug report.

[Titouan Rigoudy]

Just wanted to let you know that @ddragana from Mozilla has proposed a similar, yet slightly different approach on the RFC [1]. Does that still sound good to you? If so, I will fix up the RFC, land it and get to work implementing this.

[1] https://github.com/web-platform-tests/rfcs/pull/72

[Titouan Rigoudy]

Hi there! Friendly ping on this. Could you take a quick look at the latest version of the RFC?

[Titouan Rigoudy]

The RFC is in the end unchanged - it has only sprouted a new "alternatives considered" section to describe @ddragana's suggestion.