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

Jump to bottom

net/http: custom error handlers for http.FileServer #27139

Open
nhooyr opened this issue Aug 22, 2018 · 3 comments
Open

net/http: custom error handlers for http.FileServer #27139

nhooyr opened this issue Aug 22, 2018 · 3 comments
Labels
FeatureRequest
Milestone
Unplanned

Comments

@nhooyr
Copy link
Contributor

nhooyr commented Aug 22, 2018

Noticed that in Go 1.11 a error handler field was added to httputil's ReverseProxy to allow sending allow writing a custom error.

I think the same should be done for http.FileServer, http.ServeFile and http.ServeContent.

I don't see an easy way to do this without breaking the API or adding more API so maybe this is better for Go 2.
@nhooyr nhooyr changed the title Add error handlers to http file server Custom error handlers for http.FileServer Aug 22, 2018
@nhooyr
Copy link
Contributor Author

nhooyr commented Aug 22, 2018

This would be really janky but one way to do it would be to set the error handler within the request's context, I'm not sure if we want to go down this path though, seems like a misuse of the context.

@Azareal
Copy link

Azareal commented Aug 23, 2018 •
edited

You can do it today outside of the stdlib by wrapping the http.ResponseWriter with your own writer and intercepting the call to WriteHeader, and then, using the status code from there to decide whether you want to serve an error.

It is a little slow, involved and quirky though.

@meirf meirf changed the title Custom error handlers for http.FileServer net/http: custom error handlers for http.FileServer Aug 23, 2018
@meirf meirf modified the milestones: Go1.12, Unplanned Aug 23, 2018
@nhooyr
Copy link
Contributor Author

nhooyr commented Aug 23, 2018

Yup. The issue with that is implementing all of the response writer upgrade interfaces afterwards. Super janky especially when the underlying response writer may not support all of them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
FeatureRequest
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
3 participants
@meirf @Azareal @nhooyr