net/http: `http.StripPrefix` causing incorrect `Location` header and HTML page in 301 response

[AlexanderHott]

Go version

go version go1.23.0 linux/amd64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/ott/.cache/go-build'
GOENV='/home/ott/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/ott/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/ott/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.23.0'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/ott/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/ott/Documents/code/sandbox/go-1.23-net-http/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build887516902=/tmp/go-build -gno-record-gcc-switches'

What did you do?

When using the http.StripPrefix function for subrouting, the generated redirect page and Location header doesn't include the correct url. Note the "/api/" route and not "/api".

// main.go
package main

import (
	"fmt"
	"net/http"
)

func main() {
	router := http.NewServeMux()
	router.HandleFunc("GET /{$}", func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintln(w, "index")
	})

	v1 := http.NewServeMux()
	v1.HandleFunc("GET /api", func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintln(w, "api")
	})

	router.Handle("/v1/", http.StripPrefix("/v1", v1))

	fmt.Println("Running on http://localhost:8888")
	http.ListenAndServe(":8888", router)
}

curl to correct location: "/v1/api/"

$ curl -v http://localhost:8888/v1/api/
* Host localhost:8888 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:8888...
* Connected to localhost (::1) port 8888
> GET /v1/api/ HTTP/1.1
> Host: localhost:8888
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Mon, 16 Sep 2024 06:17:12 GMT
< Content-Length: 4
< Content-Type: text/plain; charset=utf-8
< 
api
* Connection #0 to host localhost left intact

curl to incorrect location: "/v1/api"

$ curl -v http://localhost:8888/v1/api
* Host localhost:8888 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:8888...
* Connected to localhost (::1) port 8888
> GET /v1/api HTTP/1.1
> Host: localhost:8888
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< Content-Type: text/html; charset=utf-8
< Location: /api/
< Date: Mon, 16 Sep 2024 06:17:16 GMT
< Content-Length: 40
< 
<a href="/api/">Moved Permanently</a>.

* Connection #0 to host localhost left intact

What did you see happen?

When curling the "/v1/api" route, the Location redirect header and generated html both redirect to "/api/" and not "/v1/api/".

What did you expect to see?

When curling the "/v1/api" route, I expect the Location redirect header and generated html to include the "/v1" prefix, because that is where the route is.

[gabyhelp]

Related Issues and Documentation

• net/http: 301 instead of 404 for unmatched requests #65624 (closed)
• net/http: StripPrefix does not preserve url path #24366 (closed)
• net/http: incorrectly redirect (301) if request payload include port number #51892
• net/http: path values ​​are not passed to other *http.ServeMux #69077 (closed)
• net/http: Transport does not handle 302 redirects with link-local server address correctly #20669
• net/http: redirect with 308 rather than 301 #60769
• net/http: ServeMux forcibly cleans double forward slash in URLs even when behaving as a gateway #42244 (closed)
• net/http: muxer no longer redirects host patterns in go1.10 #23183 (closed)
• net/http ServeMux clears query when redirecting #18249 (closed)
• net/http: enhanced ServerMux routing #65231 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[seankhliao]

this is working as intended. redirects are generated by ServeMux, and if it didn't know about the prefix then it can't generate the correct 300

[AlexanderHott]

Can you give an example of when this behavior is useful? I'm struggling to see how it would be a desirable output.

[QuinnCiccoretti]

Is there a way I can tell the ServeMux to generate redirects relative to the stripped prefix, "/v1", in the above example? @seankhliao