Dive deeper in the HTML for IPv6-compatiblity

[mdavids]

In Dutch:

Als je http://example.nl/ opvraagt en in de HTML die dat oplevert zit bijvoorbeeld een verwijzing naar plaatjes, fonts, JavaScript of iets anders dat van een andere website komt (bijvoorbeeld vanaf https://fonts.example.org), dan controleert internet.nl alleen maar of de HTML van example.nl via IPv6 kan worden opgehaald en wordt er niet gecontroleerd of fonts.example.org via IPv6 bereikbaar is.

De ideale situatie zou zijn dat als internet.nl zegt dat de site IPv6-compliant is, deze er ook daadwerkelijk goed uitziet over een IPv6-only verbinding. In bovenstaand voorbeeld zou dat niet zo zijn, als alleen example.nl maar via IPv6 bereikbaar is, maar fonts.example.org niet.

[nsrderooy]

Dit is een vraag om de content te parsen, dat zou alleen gedaan kunnen worden door een spider los te laten op de website, want ookal zou je doen wat de vraag was dan zou je alleen de root / van de website nagaan.

wat misschien wel mogelijk is is om naar de CSP header te kijken en deze te parsen, maar dan nog kan de CPS op / anders zijn dan op /applicatie

[mdavids]

DocumentRoot testen lijkt me afdoende (het houdt ook een keer op).

Misschien is het nog een idee om (aanklikbare) screenshots te maken; eentje van hoe de site er via IPv4-only uitziet en eentje hoe die eruit ziet over IPv6-only? Dan kan de bezoeker dit zelf een beetje visueel vergelijken. Beetje zoals https://screenshot.guru/ dus.

[nsrderooy]

screenshots zijn wel heel handmatig.

diff <(curl -4 --silent https://www.sidn.nl) <(curl -6 --silent https://www.sidn.nl)

[mxsasha]

I think the initial step is to explore ideas on how we might do this, and to what degree. Actual implementation plan (and release) can come after.

[bwbroersma]

Source code is too positive for this, even gov sites are more JS-blobs nowadays (e.g. -an already IPv4 only site- https://www.afkorijk.nl/, that needs two external XHR requests to IPv4-only API https://afko-api-production.herokuapp.com to function).

Probably better to sandbox a browser (Firefox or Chrome), do an IPv4 only and IPv6 only run and log all request errors, diff, optionally do screenshots. E.g. with pageres using the launchOptions and beforeScreenshot options:

import Pageres from 'pageres';

let fails = [];
await new Pageres({
	launchOptions: {args: ["--proxy-server=proxyhost:proxyport"]}, // or run it in an IPv6 only container?
	beforeScreenshot: async (page, browser) => {
		await page.authenticate({username: "proxyuser", password: "proxypassword"});
		page.on('requestfailed', request => {
			fails.push(request);
		});
		// Optionally also log pageerror and console
	}
})
	.source(url, ['1024x768'], {crop: true})
	.destination('screenshots')
	.run();
// compare fails array with IPv4

However: running browsers is not fast, they should be sandboxed properly, updated, etc. I'm afraid such a solution wouldn't be very low maintenance.

[stitch]

Using anything less than a common browser would not result in a complete result. This is because of javascript, webassembly, websockets / other new tech evaluated at runtime now and in the future. If you try to parse that, you're writing a browser, and those are already there.

Luckily there are several browsers/browser projects that would be usable for this purpose. The one i know, OpenWPM, does not have a v4/v6 flag but might be configured to run inside a v6 only network where v4 stuff just would not resolve (but the requests are logged without a response i guess). Puppeteer might also have support for things like this. There might be others. The network tab of a browser with an indication of v4/v6 would be sufficient i guess.

[bwbroersma]

Note that @aequitas was working (for the docker build) to add tests automation of the 4 common browsers with https://playwright.dev.