Gatling baseUrl works locally but fails in production containers: is an explicit scheme required?
0 reputation · 29 Sept 2021, 02:10 UTC
Gatling HTTP baseUrl configuration
We configure the HTTP protocol in our Gatling simulations with .baseUrl(...), and the same simulation runs successfully on developer machines but fails when executed in our production container and CI agent environments. The simulations target Gatling 3.x with the Java DSL.
Observed constraint
The value being passed resembles a bare host and port, such as localhost:8080, without an http:// or https:// scheme. Our understanding is that Gatling's underlying HTTP client may treat a scheme-less value as a relative reference rather than an absolute URI, and that resolution could then depend on the JVM working directory, which differs between local runs (project root) and containers (e.g., /opt/gatling or /app). We have not found documentation stating that Gatling validates or auto-corrects baseUrl into an absolute URI.
Open questions
1. Does Gatling require baseUrl to be an absolute URI with an explicit scheme, and is the working-directory-dependent resolution the documented explanation for environment-specific failures?
2. Does a trailing slash on the base URL change how request paths are resolved, and should it be mandated in our configuration?
3. Is externalizing baseUrl via environment variables or gatling.conf the intended mechanism for per-environment overrides without editing simulation code?
gatling