[Won't fIx - Works as expected] - Company proxy setting (for code)

Gatling version: 3.14.901 (from npx gatling --version)
Gatling flavor: typescript
Gatling build tool: npm
OS: Linux Mint 22.2

I have a company proxy. I want to test the demo script. I usually manage to make some other applications to work with it while sometimes not easy.
But here with Gatling I tried several things without success.

I tried

JAVA_TOOL_OPTIONS=“-Dhttp.proxyHost=``proxy.foobar.org``
-Dhttp.proxyPort=8080
-Dhttps.proxyHost=``proxy.foobar.org``
-Dhttps.proxyPort=8080
-Djava.net.useSystemProxies=true
-Djdk.http.auth.tunneling.disabledSchemes=” npx gatling run --typescript --simulation basicSimulation

with no luck.

npm config set proxy ``http://proxy.foobar.org:8080
npm config set https-proxy ``http://proxy.foobar.org:8080

same.

I always get a connection refused:

request count | 1 | - | 1
min response time (ms) | 106 | - | 106
max response time (ms) | 106 | - | 106
mean response time (ms) | 106 | - | 106
response time std deviation (ms) | 0 | - | 0
response time 50th percentile (ms) | 106 | - | 106
response time 75th percentile (ms) | 106 | - | 106
response time 95th percentile (ms) | 106 | - | 106
response time 99th percentile (ms) | 106 | - | 106
mean throughput (rps) | 1 | - | 1
---- Response Time Distribution ----------------------------------------------------------------------------------------
OK: t < 800 ms 0 (0%)
OK: 800 ms <= t < 1200 ms 0 (0%)
OK: t >= 1200 ms 0 (0%)
KO 1 (100%)
---- Errors ------------------------------------------------------------------------------------------------------------
j.n.ConnectException: finishConnect(..) failed with error(-111): Connection refused 1 (100%)

Where is this company proxy supposed to be set please?

Note: if I connect directly my computer to the internet it works.

You need to configure the http proxy as documented here:

Thank you for the quick answer.

Regarding “npm proxy” this is what I tried as described in my post (I guess syntax is correct) but it fails.

Regarding your second comment:
I tested this solution and it works but: I don’t think I should do it this way because code should not be environment dependent and will be versioned. If someone gets it and is not behind a proxy it will fail and he will have to modify the code.

So it seems it should work as described in you first comment but it fails. Looks like a bug on Gatling side, what do you think?

Hi,

Looks like a bug on Gatling side, what do you think?

Well, things have been working this way for a decade and you’re the first one to complain about it, so I guess most people are happy about the current design :slight_smile:

IMHO, using code make the logic way more explicit that env var or Java system properties.

pseudo-code :

val baseProtocol = http...
val finalProtocol = if (useCorporateProxy) baseProtocol.proxy(MyCorporateProxy) else baseProtocol

Hi,

Well, things have been working this way for a decade and you’re the first one to complain about it, so I guess most people are happy about the current design :slight_smile:

Sorry but 2024 is not what I would call a decade :slight_smile: :

(Post shows May 2024)

Our JavaScript SDK was introduced in 2024 but it’s modeled after the Java one that was in turn modeled after the Scala one. I don’t remember exactly when Proxy support was introduced but it was around 2014.
A decade it is.

OK but proxy is not set the same way between Java (via JAVA options variable I guess) and npm (npm set config) so IMHO it could make a difference. Don’t you think so?
There is no standard way to set a proxy for an application/program AFAIK.

Sorry, I don’t get what you mean.

Regarding proxy settings on build tools, it’s tool-specific (there’s no way npm would interpret Java Network System properties) and I don’t think it’s very useful anyway. In corporate environment, build tools typically have to download from the internal mirror than from the default repository/registry on the internet.

Regarding the Gatling load test traffic, having to use a Java-specific env var with Java net System properties wouldn’t make any sense for JavaScript users. Better have a common code syntax IMHO.

I guess there is a misunderstanding here.

Shaun pointed to this:

Configuring a proxy

If a proxy configuration is required to access the Internet, simply make sure it is configured for NPM. The gatling CLI tool will inherit the NPM proxy settings when run with npx gatling. NPM proxy settings can be configured using environment variables (HTTP_PROXY, HTTPS_PROXY, NOPROXY) or a .npmrc file, as shown in the official NPM documentation for the following configuration keys:

So I expect the following call (from the built-in demo) to respect the proxy that was set (via npm) but it is not the case:

// Define HTTP configuration // Reference: https://docs.gatling.io/reference/script/protocols/http/protocol/`
const httpProtocol = http
.baseUrl(“https://api-ecomm.gatling.io”) .acceptHeader(“application/json”) .userAgentHeader( “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36” );`

I have to pass manually the proxy to make it work (as in your example but this is not what I’d like to do) with:

.proxy(proxyConfig)

In other words I expect the proxy setting to be applied on runtime. But maybe you will say it is not supposed to work this way?

Shaun pointed to this…
So I expect the following call (from the built-in demo) to respect the proxy that was set (via npm)

No, Shaun didn’t get your question right. He asked me for confirmation and I didn’t read his message because I was on my phone. I realized my mistake and reached out to him. I’m going to delete his first answer to avoir any confusion.

Ha OK, thank you.

So if I understand well, the only way to get a HTTP request done in the code through a proxy, whatever the flavor is, is to add the proxy configuration inside the code itself, correct? Setting a proxy outside of the code has no effect on the call at all, correct?

Exactly. In particular, we don’t support https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html.