Redirects to URLS with "/../../"

From our app server (JBoss) we are getting a lot of redirects containing “relative” paths, e.g. “”. When running through a browser it manages to translate the url to the correct one, in this example “”, but when running through gatling it fails as it does not translate to the “correct” url.

Any ideas on what to do to “normalize” the url?

What’s the Location header content exactly? Is it “…/…/baz” or “…/…/baz”?

It is actually returning “…/…/baz” (at least that’s what the gatling log is telling us)

BTW, we’re using the release


This is an AHC bug actually:

Will fix, stay tuned.




Hi stepane,

Thanks! Would you mind creating a time stamped release so we can battle test it?



Hi Stéphane,

I am testing the fix now, but at some point it seems like there has been introduced a bug that normalizes a part of the path for local resources (e.g file bodies).

Here is an example of the stacktrace:

09:27:46.357 [ERROR] i.g.h.a.HttpRequestAction - Action HttpRequestAction crashed, forwarding user to next one C:\code\dokumentinnsending-gatling\target\test-classes\request-bodies%5cmyFile.ssp (The system cannot find the file specified)
at Method) ~[na:1.7.0_05]
at ~[na:1.7.0_05]
at ~[scala-reflect-2.10.2-RC1.jar:na]
at io.gatling.core.config.FileResource.inputStream(Resource.scala:31) ~[gatling-core-2.0.0-SNAPSHOT.jar:na]
at io.gatling.core.config.FileResource.inputStream(Resource.scala:30) ~[gatling-core-2.0.0-SNAPSHOT.jar:na]
at io.gatling.http.request.ELFileBodies$$anonfun$compileFile$1.apply(ELFileBodies.scala:34) ~[gatling-http-2.0.0-SNAPSHOT.jar:na]
at io.gatling.http.request.ELFileBodies$$anonfun$compileFile$1.apply(ELFileBodies.scala:34) ~[gatling-http-2.0.0-SNAPSHOT.jar:na]
at ~[gatling-core-2.0.0-SNAPSHOT.jar:na]

kl. 07:00:12 UTC+2 torsdag 20. juni 2013 skrev Stefan Magnus Landrø følgende:

Definitively a different issue.
@pdalpra, could you have a look, please?

Hi Stefan,

Probably beginning of next week, I’d like to fix a few bugs first, like the one Andreas found.




I tried reproducing the issue on my mac, but couldn’t. Could this be a windows issue?

I’ll investigate further.


Maybe the following commit introduced the issue?


Pierre said he’ll have a look this week-end, stay tuned.

Hi there,

I had a chance to look into this issue this afternoon. I’ll provide a pull request some time very soon. Stay tuned :wink:


Then I can focus on those multipart issues. I hope to be able to get something for next week so we can release 2.0.0-M3 and 1.5.2.