Forum Discussion

New Contributor

8 years ago

How does SoapUi handles 307 redirections ?

Hi. I am using SoapUI 5.3.0 and have a quick question : how does SoapUi handles 307 redirections ?

If i am not wrong, when receiving an HTTP 307 redirection response, the client can react different ways (including potentially trying interaction with user when request might not be idempotent like with POST requests).

I wish i could have soapui, when receiving a 307 response code, repost the same request to the new location, which means keeping the method (POST request should remain POST) and the content should be kept.

Is there a way to do it ?

Thanks a lot for any answer/idea or message in case my request is non-sense.

With Regards

05ten
8 years ago
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.

05ten
Contributor
8 years ago
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.
- Olga_T
  SmartBear Alumni (Retired)
  8 years ago
  Hi 05ten,
  Sorry for the inconvenience. Our system has considered your messages as spam for some reason. I have restored your message with your project attached, which, I think, is very useful. I keep tracking the spam folder for similar situations.
  Thank you for participating in the Community discussions, Osten!
- spic
  New Contributor
  8 years ago
  Clear and brillant, thank you so much 05ten for the time you spent on this question. Being very new to Soap UI i wouldn't have been able to test the way you did.
  About the expected behaviour to a 307 : yes i agree with you that it is sort of "undefined".
  I'll wait for next release to see what will be the behaviour of SoapUI but anyway in the end it shows me that we cannot expect a fixed and well defined behaviour from clients and therefore i should think of something else than sending a 307 redirection if i want my users to 100% of time redirected.
  
  Again thank you very much!
  - 05ten
    Contributor
    8 years ago
    spic wrote:
    
    Again thank you very much!
    Happy to help! :)
05ten
Contributor
8 years ago
You could test it out with a mockservice and tailor the response to return a 307 and another endpoint to point the redirect to and check if it forwards it in the correct way. I'll see if I can put something quick up.
05ten
Contributor
8 years ago
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. :)

redirect-test-soapui-project.zip2 KB