Set localAddress?

[vaultjsp]

Is it possible to set the localAddress property on the http agent? I have multiple ethernet interfaces and need requests to use a particular interface. So far my attempts have been unsuccessful; tried modifying buildProxyAgent but that didn't seem to work.

[pimterry]

For the upstream requests you mean? Not currently, no.

I'd be open for a PR for this though. I think this could be more general than proxy configuration - it's perfectly valid to configure the outbound interface for non-proxied traffic too.

Given that, I think this would be a new optional parameter for the passthrough rule. Internally Node.js supports this with the localAddress parameter on connections (I've never tried this myself, but should work for HTTP requests just fine) and we could just use the exact same thing in our API, and pass it right through.

That means adding it to the passthrough connection options (here), then using it when the request is made (here).

This will need tests somewhere, but that should be possible by setting up a raw socket server, connecting to 127.0.0.1 from a different local interface, and then just checking socket.remoteAddress on the resulting connection. There will be some plumbing required - I'd suggest starting with the test, and then working through the changes to get the option into the right place in the code and then get everything working & passing.

Does that make sense? If you're interested have a look into those details and let me know if you need any pointers.

[vaultjsp]

Thanks! Using localAddress does in fact work. It turns out I was updating the wrong http agent initially. As a quick and dirty solution, I’m using an environment variable I pass in when I start the program, but I do want to come up with a better solution. I’ll look into your suggestions. Thanks again!

On Nov 18, 2024, at 6:56 AM, Tim Perry @.***> wrote:

For the upstream requests you mean? Not currently, no.

I'd be open for a PR for this though. I think this could be more general than proxy configuration - it's perfectly valid to configure the outbound interface for non-proxied traffic too.

Given that, I think this would be a new optional parameter for the passthrough rule. Internally Node.js supports this with the localAddress parameter on connections (I've never tried this myself, but should work for HTTP requests just fine) and we could just use the exact same thing in our API, and pass it right through.

That means adding it to the passthrough connection options (herehttps://github.com/httptoolkit/mockttp/blob/c894ce1961e37a33e2681594ec92243b6aa82da6/src/rules/passthrough-handling-definitions.ts#L39), then using it when the request is made (herehttps://github.com/httptoolkit/mockttp/blob/c894ce1961e37a33e2681594ec92243b6aa82da6/src/rules/requests/request-handlers.ts#L745).

This will need tests somewhere, but that should be possible by setting up a raw socket server, connecting to 127.0.0.1 from a different local interface, and then just checking socket.remoteAddress on the resulting connection. There will be some plumbing required - I'd suggest starting with the test, and then working through the changes to get the option into the right place in the code and then get everything working & passing.

Does that make sense? If you're interested have a look into those details and let me know if you need any pointers.

— Reply to this email directly, view it on GitHubhttps://github.com/httptoolkit/mockttp/issues/184#issuecomment-2482973984, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIWUBZEPZYWPMKDCK7ZM5BT2BHPZXAVCNFSM6AAAAABR3425S2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBSHE3TGOJYGQ. You are receiving this because you authored the thread.Message ID: @.***>