From our app server (JBoss) we are getting a lot of redirects containing “relative” paths, e.g. “http://my-site.com/foo/bar/../../baz”. When running through a browser it manages to translate the url to the correct one, in this example “http://my-site.com/baz”, 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 “http://my-site.com/foo/bar/…/…/baz” or “…/…/baz”?
It is actually returning “http://my-site.com/foo/bar/…/…/baz” (at least that’s what the gatling log is telling us)
BTW, we’re using the 2.0.0.20130605 release
Hi,
This is an AHC bug actually: https://github.com/AsyncHttpClient/async-http-client/issues/329
Will fix, stay tuned.
Cheers,
Stéphane
Fixed
Hi stepane,
Thanks! Would you mind creating a time stamped release so we can battle test it?
Cheers
Stefan
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
java.io.FileNotFoundException: C:\code\dokumentinnsending-gatling\target\test-classes\request-bodies%5cmyFile.ssp (The system cannot find the file specified)
at java.io.FileInputStream.open(Native Method) ~[na:1.7.0_05]
at java.io.FileInputStream.(FileInputStream.java:138) ~[na:1.7.0_05]
at scala.reflect.io.File.inputStream(File.scala:97) ~[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 io.gatling.core.validation.Success.map(Validation.scala:26) ~[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.
Cheers,
Stéphane
Ok.
I tried reproducing the issue on my mac, but couldn’t. Could this be a windows issue?
I’ll investigate further.
Stefan
Maybe the following commit introduced the issue?
7219a263bc310e1aea097f0627e5a7486b13d757
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 
Great!
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.