I am using gatling to test our env with and without Akamai CDN.
During the tests with Akamai turned on, each POST to the application which should end with 400 error (proper system behaviour for my test case) I get 411 response from Akamai.
This error means that there was no content length header set during the request. Is there any other way, beside turning off follow redirect, to solve my issue?
Header propagation during redirects is something that’s not properly described in RFCs. So we do our best to match what browsers do, but that’s more of a trial and error as of course it’s not documented.
Could you provide a reproducer exhibiting the issue, please?
What do you mean by reproducer?
W dniu wtorek, 6 października 2015 09:17:39 UTC+2 użytkownik Stéphane Landelle napisał:
A test case, a sample that one could run with a browser and reproduce your issue.
In browser this issue does not occur. Only by gatling.
exec(http("[POST] save time")
.formParam("timeSpent", ThreadLocalRandom.current().nextInt(0, 300000))
W dniu wtorek, 6 października 2015 09:43:08 UTC+2 użytkownik Stéphane Landelle napisał:
“A test case, a sample that one could run with a browser and reproduce your issue.”
How is someone supposed to run your simulation extract?
If you would like I can prepare you an env that you could run this scenario.
val login = exec(
http("[GET] Login Page")
http("[POST] Login Check")
val scn = scenario(“Student solve - Bad request”)
).exec(http("[POST] save time")
.formParam(“timeSpent”, ThreadLocalRandom.current().nextInt(0, 300000))
rampUsers(1) over(20 seconds)
this is all I got
W dniu wtorek, 6 października 2015 10:18:10 UTC+2 użytkownik Stéphane Landelle napisał:
Or if your system is already live, you can grant me access (privately) and show me how to trigger the action that fails with Gatling.
I need to see what the browser does exactly.
OK. I’ll send you an email with details later during the day. I’ll will prepare user account for you on our perf environment (same as proudction).
W dniu wtorek, 6 października 2015 10:58:55 UTC+2 użytkownik Stéphane Landelle napisał:
Ok to close the topic.
So, the situation was, that my initial post was wrong.
Actually issue was on redirect, but not on this particular action. My system on submit did redirect with 301 status response.
Browser did POST → 301 → GET, to avoid double posting the content, but actual my application should return 303 status code in response for POST.
Gatling worked as expected. When I updated the application to respond with 303 status, everything worked fine.
As Stéphane Landelle pointed correctly “…even though they shouldn’t (as per RFC2616), browsers switch to GET on 301 redirect. This is a long running RFC misinterpretation…”
There is a Wiki post about this issue:https://en.wikipedia.org/wiki/Post/Redirect/Get