net/http: StripPrefix regression from fix for #30165 #31622
The fix for #30165 breaks code relying on the stripped prefix to elide a leading
I raise this only because I have a test that ensures a response cannot change; that test failed on tip.
What did you do?
What did you expect to see?
What did you see instead?
Does this issue reproduce with the latest release (go1.12.4)?
No, tip only.
I suspect this is an unfortunate but intended consequence of fixing #30165. Code relying on that should be updated not to rely on it. That is, instead of:
http.Handle("/foo/", http.StripPrefix("/foo/", h))
It makes more sense to me to be writing:
http.Handle("/foo/", http.StripPrefix("/foo", h))
That leads to a more consistent behavior. Handlers almost always receive absolute request paths, and trying to handle or support paths that don't begin with a "/" is often going to be problematic or impossible.
But I'll let Brad see if anything else can/should be done. /cc @bradfitz
I agree it's a consequence, but it it is misleading to start with a cleaned path, strip a known prefix, and end up with a result where the full prefix was not stripped. Handlers that are coded to only be behind StripPrefix now have to also know that maybe a slash is not stripped, even if requested.
The original problem exists because the file server is relying on r.URL.Path to be non-empty; the fix should be to check that it is non-empty before indexing into the path. The original code should also likely just be using FileServer.