net/http: StripPrefix creates a new request, confusing middleware

[heschik]

As of http://golang.org/cl/36483, StripPrefix creates a new request with the modified URL rather than modifying the existing request. That means that the identify of the request object can change between different handlers. If an earlier handler used a map[*http.Request], and then a later handler tries to read that value, it won't find it. This broke one important Google-internal use case, and a Github search shows a lot of such maps, so it may be worth addressing. I don't know how given the conflicting requirement to not modify the request.

[dsnet]

\cc @bradfitz

[bradfitz]

@quentinmit had brought this up as a concern at #18952 (comment)

I'm still inclined to fix the affected code, though. Relying on *http.Request pointer equality down a chain of wrappers already seems dicey. I'll look at the internal bug.

[heschik]

Perhaps a release note?

[rsc]

Agree with Brad. It's fine to add a release note warning, but we've been making copies of Requests since at least Go 1.8's WithContext. Middleware should also be using context at this point I would imagine.

[gopherbot]

CL https://golang.org/cl/48190 mentions this issue.