net/http: ServeFile generates wrong links in a directory when a path doesn't end in a slash #16424
Comments
|
rfc 2616 and 4918 are mute on what happens when you request a representation of a collection (rfc 4918 terms for a directory) without the trailing slash. To be explicit, rfc 4918 defines is a collection is not defined (by my reading). There are two possibly solutions I can see: a. |
|
It seems that option a is implemented already - https://golang.org/src/net/http/fs.go?s=14478:14535#L379 but it is explicitly turned off in the case of ServeFile |
|
@solarsea i'm sorry i don't understand, can be more explicit please. |
|
ServeFile uses serveFile internally - https://golang.org/src/net/http/fs.go#L353. The later has a parameter called 'redirect' that when true already implements the behavior that you suggest - that /dir should redirect to /dir/ |
|
I think that a straightforward fix is to drop the 'redirect' parameter of serveFile(...) altogether and therefore unify ServeFile(...) and FileServer(...) behaviors |
ianlancetaylor
changed the title
|
Yeah I think this is a dup. |
|
It is a dup, but the fix looks weird. It is adding corrective code, instead of fixing it by removal of the defective flag. |
|
Glad to hear it's fixed. Feel free to send a change if you have something which makes the code more clear. I'm just happy we have a test for it now. |
Please answer these questions before submitting your issue. Thanks!
go version)?go version go1.6.2 windows/amd64
go env)?Windows, amd64
I ran the program with the directory structure "c:/temp/dir1/file.txt" and opened
both "http://localhost/dir1/" and "http://localhost/dir1" (without trailing slash)
/-------------------------------------------------------------
package main
import (
"net/http"
)
func main() {
http.ListenAndServe(":80", http.HandlerFunc(func(rw http.ResponseWriter, req *http.Request) {
http.ServeFile(rw, req, "C:/temp")
}))
}
/-------------------------------------------------------------
Same html output for both.
The URL without the trailing slash shows correct directory content but generates a wrong link in the form of "http://localhost/file.txt" instead of "http://localhost/dir1/file.txt"
The text was updated successfully, but these errors were encountered: