I have a piston that sends both GET and PUT web requests to the same URL (of the form https://address/…, using a basic authentication type authorization header like “Bearer xxx”.) The GET request works fine, but the PUT request results in an $httpStatusCode of 307.
I tried both of these same requests using Postman (with “Automatically follow redirects” turned off), and I see that the server responds to both with a status of 307 and provides the redirection URL in the Location header. (To be clear, it provides the same redirection URL to both requests.) If I reconfigure Postman to automatically follow redirects, then both requests succeed with a status of 200.
As a temporary workaround in my WC piston I changed the web requests to use the redirection URL I obtained using Postman instead of the original URL, and in both cases (GET & PUT) they now work. Of course, if the server provides a different redirection URL in the future, my piston will stop working until I go through the same process again to get the new redirection URL via Postman.
Note that the API docs of the server I’m interacting with specifically mention redirects and suggests caching the redirect URL and using that instead of the original URL unless the redirect URL eventually no longer works, in which case, the original URL should be used again to obtain (& cache) a new redirect URL.
So the questions are:
- Why doesn’t a PUT web request in WC automatically follow redirects when a GET web request does?
- Is there anything that can be done to get PUT web requests to automatically follow redirects?
- This is more of a related feature request, but can the redirect URL be made accessible (e.g., via a new system variable such as $httpRedirectURL) if redirection happens so that the piston that invokes the web request action can cache the URL and use it in the future? This will reduce network traffic and the number of HTTP requests seen by the server.