Request is not forwarded properly by the proxy

[allansson]

Describe the bug

For some reason the proxy is failing to forward certain requests to the server.

One example I've found is this URL:

https://tvspix.com/t.png?&t=1770312184242&l=tvscientific-pix-o-e60d9a8a-65c7-422b-a6ef-12e8d481fa9b&u3=https%3a%2f%2fwww.vistaprint.com%2f

This is a tracking pixel from tvScientific and it's being used by vistaprint.com.

It's not a big deal that this particular URL isn't working while recording, but it:

1. interacts with the browser debugger in weird ways, and
2. is a sign that there are certain types of requests that we can't record properly

In browser scripts, the goto and waitForNavigation events will wait for the page load event to fire before continuing. The load event is executed after all the assets (stylesheets, images, script, etc.) have been loaded.

Since the proxy fails to forward the request the browser is stuck waiting for it to finish. Consequently, the goto and waitForNavigation will also get stuck. Eventually, the request times out and only then is the load event emitted.

The timeout for the browser seems to be about ~30 seconds, which is the same as the default timeout for goto and waitForNavigation. This means that most (but not all) of the time these calls will fail the test.

Steps to reproduce the problem

1. Go to Start a new recording
2. Enter the following start URL: https://tvspix.com/t.png?&t=1770312184242&l=tvscientific-pix-o-e60d9a8a-65c7-422b-a6ef-12e8d481fa9b&u3=https%3a%2f%2fwww.vistaprint.com%2f
3. Start the recording

Expected behavior

The request should go through like it does if you try to access it directly

Actual behavior

The request hangs until it times out after ~30 seconds.

Grafana k6 Studio version

1.10.0

OS

macOS

[Llandy3d]

The reason for this issue is that the dns return both ipv6 and ipv4 addresses for the server but the ipv6 one is not actually working and it's what a connection would prefer for a first attempt. This would hang for 4-5~ minutes and then work on the ipv4 one, but we timeout after 30s for the load event.

This should be solved ideally by I guess:

1. Do not return from your service an address that doesn't work
2. More gracefully handle the scenario at the proxy level with the happy eyeballs algorithm

I've created an issue for the proxy with more details:

• Add support for the happy eyeballs algorithm to better handle ipv6 and ipv4 connections mitmproxy/mitmproxy#8088