net/http: add ServeContent

[bradfitz]

Because http.ServeFile doesn't work with a vfs (yet?) I was trying to use
http.FileServer with a vfs and faking my the http Request.URL.Path to make FileServer
serve the virtual file I wanted.

My input URL was /ui/ and I was faking the request to the VFS for /index.html, because
that's the file I wanted to serve.

The FileServer then redirected me to "/", because it was trying to strip the
index.html from the URL.

That's a bit weird. All other filenames work fine.

I guess I can't use the filename index.html.

[rsc]

Comment 1:

Nope.  I tried very hard to make each file be
served under a unique URL.  Since / serves index.html,
/index.html cannot.
FileServer is a convenience function.  It's not
meant to be all things to all people.
Russ

[bradfitz]

Comment 2:

The issue remains that http.FileServer is the only path I have to get to the meaty
http.serveFile (unexported, taking a VFS) since http.ServeFile only uses the host
filesystem.
So it's not that convenient.  I'd happily use something else if I could.

[adg]

Comment 3:

So the issue is that there should be a public ServeFile that uses an http.FileSystem?

[bradfitz]

Comment 4:

That was the original CL but we hit a complication with relative filenames.

[bradfitz]

Comment 5:

From Andy Balholm:
"""
Thanks, Brad. I tried it out in my server, and it works.
But now it exposes another problem: redirects.
The fileHandler redirects requests for /index.html to / . But since it's running under
StripPrefix, the user really requested /static/index.html (in this case), and he should
be redirected to /static/ .
It's easy enough to fix on my site, since I was redirecting / to /static/index.html
already. I just redirected / to /static/ instead. (I really ought to eliminate the
/static directory entirely, but that's another issue.) But I'm puzzled about how to fix
it in the general case. Ideally, it would be nice to be able to fix redirects issued
even by user code (not just by FileServer), but how would you do that?
"""

[rsc]

Comment 6:

i would much rather expose serveFile somehow
than try to make FileServer all things to all people.

[andybalholm]

Comment 7:

Maybe the old FileServer could be reinstated as SimpleFileServer or something. It seemed
to work fine for what I was doing.

[rsc]

Comment 8:

Labels changed: added priority-later, removed priority-medium.

[rsc]

Comment 9:

Labels changed: added priority-go1.

[bradfitz]

Comment 10:

We currently have:
   236  // ServeFile replies to the request with the contents of the named file or directory.
   237  func ServeFile(w ResponseWriter, r *Request, name string) {
   238      dir, file := filepath.Split(name)
   239      serveFile(w, r, Dir(dir), file, false)
   240  }
... where the FileSystem (Dir(dir)) cannot be controlled.  This is the only path to
serveFile.
Can we export "serveFile" with some new non-conflicting name?

[robpike]

Comment 11:

Owner changed to builder@golang.org.

[adg]

Comment 12:

http://golang.org/cl/5541059/

Status changed to Started.

[rsc]

Comment 13:

Might well be Status: Unfortunate.

[rsc]

Comment 14:

Labels changed: added go1-must.

[rsc]

Comment 15:

I think I could get behind
// ServeContent replies to the request using the content of the reader r.
// The main benefit of ServeContent over io.Copy is that it handles Range
// requests properly.  Note that *os.File implements the io.ReadSeeker interface.
func ServeContent(w ResponseWriter, req *Request, r io.ReadSeeker)
This does not have to be done before Go 1.

Labels changed: added priority-later, removed priority-go1, go1-must.

Status changed to Accepted.