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
net/http: request.Method is wrong when path start by // #29584
Comments
/cc @bradfitz |
@eraac With this patch:
You will get expected result. But IMHO, we should return 500 error with a message like redirect with form data without user interaction won't be perform. HTTP spec requires 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 How do you think @bradfitz ? |
I studied how other CLI HTTP clients (like server.go package main
import (
"fmt"
"log"
"net/http"
"net/http/httputil"
)
func main() {
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
// debug incoming requests
reqd, err := httputil.DumpRequest(r, false)
if err != nil {
log.Println(err)
}
fmt.Printf("\n[request]: %s\n", reqd)
w.WriteHeader(http.StatusOK)
})
fmt.Println("starting server on http://localhost:8080")
if err := http.ListenAndServe(":8080", http.DefaultServeMux); err != nil {
log.Fatal(err)
}
} 1. curl
2. http
client.go
The reason this happens could be due to following the internally-generated redirect for the initial request
Thoughts @bradfitz ? |
I was reading more about this today and I found that we are redirecting all HTTP requests (except "HEAD" requests) using a new "GET" request via RFC 7231 categorically explains the use of GET method for automatic redirection:
As a result, we have to explicitly restrict the client from automatically following any redirects by via After this research, I do not think of this issue as a bug/unexpected behaviour but rather a conscious decision from the team with proper documentation. Based on the practical nature of the use case and the buzz on SO around this question, the only suggestion I have would be to empower the end-users with a suitable interface for creating such no-redirect-following clients from the standard library package itself. This would just be a syntactic sugar - another level of abstraction. I defer to the opinion of far more experienced engineers here. net/http/client.go
end-user/client.go
References: |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
send post request with url start with two // (tbh it's was a mistake)
What did you expect to see?
server receive a post request
What did you see instead?
server receive a get request
Code
Output
The text was updated successfully, but these errors were encountered: