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

[pstibrany]

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]

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.

[ianlancetaylor]

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]

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]

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.

[davecheney]

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.