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: custom error handlers for http.FileServer #27139

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

Comments

Projects
None yet
3 participants
@nhooyr
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 from Add error handlers to http file server to Custom error handlers for http.FileServer Aug 22, 2018

@nhooyr

This comment has been minimized.

Contributor

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

This comment has been minimized.

Azareal commented Aug 23, 2018

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 from Custom error handlers for http.FileServer to net/http: custom error handlers for http.FileServer Aug 23, 2018

@meirf meirf modified the milestones: Go1.12, Unplanned Aug 23, 2018

@nhooyr

This comment has been minimized.

Contributor

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