New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
net/http: serveContent() via FS() fails when the fs.File does not implement io.Seeker and content-type cannot be determined from filename #44553
Comments
Thank you for filing this issue @pdmccormick and welcome to the Go project! Thank you @seankhliao for the triage! @pdmccormick the contract for http.ServeContent firmly requests that an io.Seeker be passed in, as has been for the past 9 years Breaking this contract might be forward compatible, but it'll introduce unknown behavior and it renders http.ServeContent useful defeating its make up. The seek method is also later used to determine the size. For common usage, we recommend using http.Dir(DIRECTORY_ROOT") https://golang.org/pkg/net/http/#Dir In what cases in the wild would it be possible to have a non-artificial fs.FS that doesn't implement io.Seeker? |
Thanks @odeke-em for the review and feedback. I suppose my problem is not so much with I came across this issue when creating a gzip decompressing filesystem wrapper: when asked to open |
Edited title to clarify that it is |
I think I've run into this exact issue by trying to open https://golang.org/src/mime/type_windows.go (linked to from https://golang.org/src/mime/) |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Using
http.FS
with anfs.FS
that does not returnio.Seeker
files will fail to serve if the content-type cannot be guessed from the filename.Here is a testcase
bug_test.go
:(play.golang.org is currently running Go 1.14, but this testcase relies on
io/fs
from 1.16)What did you expect to see?
When the content-type cannot be guessed from the filename, and when the content itself is not seekable, I would suggest that returning
application/octet-stream
would be a reasonable default.What did you see instead?
HTTP response code 500 with body
seeker can't seek
(coming from https://github.com/golang/go/blob/master/src/net/http/fs.go#L243 ).Suggested fix
The following patch to
src/net/http/fs.go
works around the case where*http.ioFile
is being used to wrap anfs.File
(viahttp.FS
) and add aSeek
method, even when a givenfs.File
doesn't implement it (see https://github.com/golang/go/blob/master/src/net/http/fs.go#L774-L780):The text was updated successfully, but these errors were encountered: