Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
net/http: 301 redirects after a 303 redirect from a POST request don't work #9348
Hello everyone (reading this)
I'm building a tool that fetches a URL from a POST endpoint, which returns a
Here's the issue: Go seems to process the redirect from the
But once we get to the
This seems odd to me. Seems like it could be a bug. Am I missing something? If this is a bug, would a fix for this make sense considering BC?
I'm posting this on behalf of my current employer, shopping24 GmbH.
changed the title
301 redirects after a 303 redirect from a POST request don't work
Dec 17, 2014
Also an additional related question, as I couldn't find it stated explicitly in sources, and after googling around I'm still not certain: are 301 and 307 not followed in http.Post() (and .Do() with POST) specifically because they Require Interaction From User as per the RFCs? If so, could this possibly be noted explicitly in the comment above http.Post(), that this is left as an excercise for the reader?
@akavel, Here's my understanding of it...
RFC 2616 (HTTP/1.1 June 1999) does state that clients must not automatically redirect POST requests that return 301 or 307. (Only GET and HEAD may be automatically redirected.) But it also says the same thing for 302.
I think the underlying principle of the matter is that if the client is going to resend the POST request body data, then RFC 2616 wants clients to get the user's consent. The trouble is that most client implementations did not resend the POST data when following 301 or 302 redirects. So the principle of getting user consent doesn't really apply.
RFC 7231 (HTTP/1.1 June 2014) changes this. It ratifies the common behavior of 301 and 302 (to not re-POST), and in doing so it leaves it up to the client to determine when it is safe to automatically redirect.
I think good default behavior for net/http would be to automatically follow redirects only for status codes where data is not re-POSTed. Consequently, if it handles 301s as POST/301/GET, then it should have no reason to not automatically follow the redirect.
I'm not sure what net/http/client does in every scenario, but I believe all of the following would be technically legal behaviors, paired with the auto-redirect behavior I'd expect of each client behavior:
Getting back to this bug report...