-
Notifications
You must be signed in to change notification settings - Fork 705
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Method changes on redirect #319
Comments
@OJFord I think you can take full control of all redirect(s) via policy. By default resty does not assign any redirect policy to the client. |
@jeevatkm I'm not sure I understand - would it ever be desirable that a POST resulting in a redirect ends up being a GET on the redirected-to resource? The behaviour I saw by default (not specifying a redirect policy) was the same as when I supplied one that allowed the redirect ( |
@OJFord It certainly possible. Because on the server-side if they redirect POST to GET then HTTP clients simply going to follow the redirects. So the client is not going to take a decision on its own. Define a custom redirect policy on your client to investigate it. client.SetRedirectPolicy(RedirectPolicyFunc(func(req *http.Request, via []*http.Request) error {
// log all the info you want for the investigation
return nil
})) If you do not want to follow the redirect kindly use |
The redirect response is
The response is just:
I do want to follow the redirect, I just don't want the method to change. |
@OJFord will check it again in Resty. Just want to clarify, you're using Resty v2 correct? |
Sorry for the delay - v2, yes. |
I have the same problem, I send a POST request and it returns 405 because it is changed to GET upon redirect. |
@MrNocTV Yep, as far as I recall I just got around this by not having using the redirected endpoint in the end. Not as easy it sounds because of some other issue with trailing slashes or something (which was why it was redirecting), but that was easier to solve in the end. |
@OJFord Can you please share an example :D ? |
@MrNocTV Depends on the API you're using, try in the browser or with curl, check the redirect Location, and use that in your code instead of the one that gets redirected. This assumes it's a static/deterministic-in-known-way redirect though; again, depends on API and why it's redirecting. |
I was struggling with a similar problem, until I noticed that that method change seems to be the right behavior, depending on the server's status code. According to Go's
We've just changed the method from Maybe It isn't the same problem, but I think it could help in some way. |
Oh interesting, thanks for that. I suppose that explains it then - but frustrating if you're working with a third-party API that behaves differently, even if that isn't RFC compliant. ... Actually though RFC2616 implies that the method should be retained ('when automatically redirecting a POST request'); what it does say - and I wonder if the docs quoted above are perhaps a misreading of this? - is that the user agent must not follow the redirect without confirmation, unless it's GET or HEAD. (In the context of a programming library user agent, I suppose 'user confirmation' is something like setting a Edit: there is also this note:
But I think that's been misapplied to 301. |
If the redirect policy allows redirection, and the request method was initially
POST
; on the redirected request it's no longerPOST
, and the response may be405 Method Not Allowed
(very confusing if the logs aren't showing that redirection happened!) or an unexpected response/effect in the event that the method is allowed.The text was updated successfully, but these errors were encountered: