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: serveContent should 500 instead of 404 on error #10283

Closed
bradfitz opened this issue Mar 29, 2015 · 2 comments
Closed

net/http: serveContent should 500 instead of 404 on error #10283

bradfitz opened this issue Mar 29, 2015 · 2 comments
Milestone

Comments

@bradfitz
Copy link
Contributor

http's fs.go contains:

        f, err := fs.Open(name)
        if err != nil {
                // TODO expose actual error?                                                                                                                                                
                NotFound(w, r)
                return
        }
        defer f.Close()

        d, err1 := f.Stat()
        if err1 != nil {
                // TODO expose actual error?                                                                                                                                                
                NotFound(w, r)
                return
        }

This bug is about those TODOs.

We should send a 500 instead of a 404. Sending the actual error text is probably too risky (might contain sensitive information). Instead, we could just log it.

@bradfitz bradfitz self-assigned this Mar 29, 2015
@bradfitz bradfitz added this to the Go1.5 milestone Mar 29, 2015
@asergeyev
Copy link
Contributor

Brad it's not quite correct, if error is permission-related, the web-servers normally give 403. Non-existing files return 404.

I can imagine there should be errors that should result in 500 but normally two above should handle most of the cases (*CGI, proxying and SSI are usual suspects for 500)

@bradfitz
Copy link
Contributor Author

@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

3 participants