How does SoapUi handles 307 redirections ?

I made a tiny project with a rest mockservice that tests this. 

POST /shouldRedirect  -> returns 307 with header Location: http://localhost:8080/shouldOnlyAcceptPost). 

POST /shouldOnlyAcceptPost -> Was redirected with post

GET /shouldOnlyAcceptPost --> Did not get a post, got a GET

Also a testsuite and a teststep that starts the mockservice and triggers POST on /shouldRedirect and asserts that the response contains was redirected with post. 

Results:

The test fails as i'm redirected to GET /shouldOnlyAcceptPost, see the project attached to post. 

So i started digging into the HTTP RFC 2616 to see how this should be handled and stumbled upon the following. 

10.3.8 307 Temporary Redirect

   If the 307 status code is received in response to a request other
   than GET or HEAD, the user agent MUST NOT automatically redirect the
   request unless it can be confirmed by the user, since this might
   change the conditions under which the request was issued.

So the behavior is sort of undefined. For 301 there's an addition that states that some existing user agents for HTTP/1.0 erronously changes it to GET. Which feels like the behavior that is in SoapUI right now. 

10.3.2 301 Moved Permanently

      Note: When automatically redirecting a POST request after
      receiving a 301 status code, some existing HTTP/1.0 user agents
      will erroneously change it into a GET request.

So i did some digging, and found the line that follows redirects for HttpRequests, and i can confirm that all redirect response codes are being treated equally. Meaning that no matter the redirect type all requests are being transformed, erronously into a HTTP GET at line 318 for the 5.3.0 release. 

The good news: 

I checked out the code in next (the next release branch) and noticed that line numbers have changed and found the following commit. And it sports a fix for the problem that makes SoapUI switch to GET method. However, its only a fix for POST and technically goes against the RFC. But it should resolve your issues. So get your hands on a nightly build, build SoapUI yourself or wait for the release of SoapUI 5.4.0 when this should be included. :)

I have checked it out and can verify that my test passed on next. 

This reply grew out of the proportions i had in mind at start, but i hope it helps. For some reason my post is removed all the time, not sure why but might be the project i attached, but i hope this helps anyway without it.