Skip to content
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: FileServer with "/proc" directory doesn't work on Linux #10699

Closed
pstibrany opened this issue May 5, 2015 · 5 comments
Closed

net/http: FileServer with "/proc" directory doesn't work on Linux #10699

pstibrany opened this issue May 5, 2015 · 5 comments
Milestone

Comments

@pstibrany
Copy link

http.FileServer doesn't work with files in /proc on Linux. It gets the directories right, but files cannot be downloaded. They are returned with Content-Length: 0 instead.

I would prefer to get the content of the files.

package main

import "net/http"
import "log"

func main() {
    http.Handle("/", http.FileServer(http.Dir("/proc")))
    log.Fatal(http.ListenAndServe(":8080", nil))
}

Using go version go1.4.2

$ curl -v http://localhost:8080/diskstats
* Hostname was NOT found in DNS cache
*   Trying ::1...
* Connected to localhost (::1) port 8080 (#0)
> GET /diskstats HTTP/1.1
> User-Agent: curl/7.37.1
> Host: localhost:8080
> Accept: */*
> 
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Length: 0
< Content-Type: text/plain; charset=utf-8
< Last-Modified: Tue, 05 May 2015 13:57:42 GMT
< Date: Tue, 05 May 2015 13:57:42 GMT
< 
@bradfitz bradfitz changed the title http.FileServer with "/proc" directory doesn't work on Linux net/http: FileServer with "/proc" directory doesn't work on Linux May 5, 2015
@bradfitz
Copy link
Contributor

bradfitz commented May 5, 2015

This is because the Linux /proc filesystem lies (is lazy) and says that files are 0 bytes long, which we trust.

I suppose we could never trust 0-length files and just serve them without a Content-Length, and also disable caching and Range and such.

@bradfitz bradfitz added this to the Go1.6 milestone May 5, 2015
@ianlancetaylor
Copy link
Contributor

It's probably not worth it, but if the file is zero length you could call syscall.Statfs(path, &statfs) and check for statfs.Type == 0x9fa0 (aka PROC_SUPER_MAGIC, but syscall doesn't define that yet). For completeness you would also want to check for 0x62656572 (aka SYSFS_MAGIC) since the files under /sys also don't have the right length.

@bradfitz
Copy link
Contributor

bradfitz commented May 5, 2015

I don't think I want to sniff for procfs. Not only does that mean fighting through potentially layers of Go interface types to type-assert things, but it means it still wouldn't work if e.g. an sshfs filesystem was on top of a remote proc filesystem and we were trying to serve that wrapper filesystem.

@robpike
Copy link
Contributor

robpike commented May 5, 2015

I think it's a mistake to do anything about this. Accessing such files through a web server is too dangerous to provide a general mechanism like this.

@robpike robpike closed this as completed May 5, 2015
@davecheney
Copy link
Contributor

I think it's a mistake to do anything about this. Accessing such files through a web server is too dangerous to provide a general mechanism like this.

I agree. You should have to go out of your way to do this.

@golang golang locked and limited conversation to collaborators Jun 25, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants