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

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


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

In Chrome this results in a subsequent POST to 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 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 HTTP/1.1 with a response HTTP/1.1 405 Method Not Allowed

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


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

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)?

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