# Does a POST that results in a redirect get turned into a GET (instead of remaining a POST)?

**URL:** <https://community.gatling.io/t/does-a-post-that-results-in-a-redirect-get-turned-into-a-get-instead-of-remaining-a-post/4358>\
**Category:** Gatling (Open-Source)\
**Created:** [June 7, 2018, 5:00pm UTC](https://community.gatling.io/t/does-a-post-that-results-in-a-redirect-get-turned-into-a-get-instead-of-remaining-a-post/4358 "2018-06-07T17:00:21Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![David\_Miller](https://avatars.discourse-cdn.com/v4/letter/d/d6d6ee/32.png) [@David\_Miller](https://community.gatling.io/u/David_Miller)\
**Post date:** [June 7, 2018, 5:00pm UTC](https://community.gatling.io/t/does-a-post-that-results-in-a-redirect-get-turned-into-a-get-instead-of-remaining-a-post/4358/1 "2018-06-07T17:00:21Z")

</div>

Hi all,  
I have some code that looks something like this

.exec(http(“request\_52”)  
.post("/service/login")  
.headers(headers\_52)  
.body(RawFileBody(“RecordedSimulation\_0052\_request.txt”)).check(bodyString.saveAs(“result”)))

the result of this call is “HTTP/1.1 301 MOVED PERMANENTLY” and gives back [https://myserver:443/service/login](https://myserver:443/service/login) (Note the http**s)**

In Chrome this results in a subsequent POST to [https://myserver:443/service/login](https://myserver:443/service/login) with the same content.

In Gatling I _think_ this results in a a GET to [https://myserver:443/service/login](https://myserver:443/service/login) instead of a POST

In my actual application sending a GET to this URL returns a 405 not allowed (as this endpoint only accepts POST)  
This means my Gatling script fails as it is getting a 405, also the server is in the wrong state as it hasn’t had a successful POST.

I’ve set up fiddler and my script is set to proxy both http/https traffic to fiddler.  
In fiddler I see

- POST /service/login HTTP/1.1 with a response HTTP/1.1 301 MOVED PERMANENTLY, then
- CONNECT myserver:443 HTTP/1.1 with a response HTTP/1.1 200 Connection Established, then
- GET to [https://myserver/service/login](https://myserver/service/login) HTTP/1.1 with a response HTTP/1.1 405 Method Not Allowed

Any ideas? Have I found a bug or am I misreading?

Thanks!  
Dave.

---

<div class="post-metadata">

**Author:** ![David\_Miller](https://avatars.discourse-cdn.com/v4/letter/d/d6d6ee/32.png) [@David\_Miller](https://community.gatling.io/u/David_Miller)\
**Post date:** [June 7, 2018, 5:03pm UTC](https://community.gatling.io/t/does-a-post-that-results-in-a-redirect-get-turned-into-a-get-instead-of-remaining-a-post/4358/2 "2018-06-07T17:03:53Z")

</div>

Aha a thing has just occurred which is maybe HTTP POST redirect isn’t supported in HTTP specification, I’ll need to check that…

---

<div class="post-metadata">

**Author:** ![slandelle](https://dub1.discourse-cdn.com/flex013/user_avatar/community.gatling.io/slandelle/32/4_2.png) [@slandelle](https://community.gatling.io/u/slandelle)\
**Post date:** [June 7, 2018, 6:18pm UTC](https://community.gatling.io/t/does-a-post-that-results-in-a-redirect-get-turned-into-a-get-instead-of-remaining-a-post/4358/3 "2018-06-07T18:18:17Z")

</div>

[https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections](https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections)

Original HTTP redirect status were poorly specified, hence the multiple possible behaviors.  
Then, please understand that combining redirects and request bodies is not a great idea: what if the body was already consumed and cannot be recomputed (eg a stream)?

---

<div class="post-metadata">

**Author:** ![David\_Miller](https://avatars.discourse-cdn.com/v4/letter/d/d6d6ee/32.png) [@David\_Miller](https://community.gatling.io/u/David_Miller)\
**Post date:** [June 11, 2018, 10:53am UTC](https://community.gatling.io/t/does-a-post-that-results-in-a-redirect-get-turned-into-a-get-instead-of-remaining-a-post/4358/4 "2018-06-11T10:53:22Z")

</div>

Hi Stéphane,  
Yep, thanks for your reply.  
I can change my recording/application to trivially avoid this redirection occurring, and that seems to work.  
Yes, I see what you mean re: HTTP specification, in our context we should probably be using 308 rather than 301  
Thanks,Dave.
