net/http: Add Error Callbacks #21548

theory · 2017-08-21T20:27:06Z

I've written a little REST server on net/http that's supposed to only ever return JSON contents. At least, that's what the parts I wrote do. However, there are certain errors that net/http encounters before my code is ever called. In those situations, I have no access to any code to determine what the content type and message should be for a given error. For example, take this stupid simple implementation:

package main

import (
	"encoding/json"
	"net/http"
)

type Server struct{}

func (server *Server) ServeHTTP(w http.ResponseWriter, r *http.Request) {
	w.Header().Set("Content-Type", "application/json; charset=UTF-8")
	w.WriteHeader(http.StatusOK)
	if err := json.NewEncoder(w).Encode(http.StatusText(http.StatusOK)); err != nil {
		panic(err)
	}
}

func main() {
	http.ListenAndServe(":8080", &Server{})
}

If I submit a request with borked headers (this one has a wayward newline in the Authorization header), my ServeHTTP() method is never called, presumably because there's an error when parsing the request to create the Request object:

> curl -i -H 'Authorization: Basic hi
there' 'http://localhost:8080/'
HTTP/1.1 400 Bad Request
Content-Type: text/plain; charset=utf-8
Connection: close

400 Bad Request

This makes complete sense to me, but if I'm creating an API with a contract to only ever return JSON, I'd like to have some way to plug into this error response and set the content-type and the body. I think the same challenge exists for Not Found errors. Perhaps there could be special handlers to configure these situations, similar to how Gorilla mux provides an assignable NotFoundHandler field in its Router object?

I'm not sure exactly what a generalized interface would look like for such error handlers (methods on Handler protocol?), but some way to hook in and get some control over net/http-initiated error responses would be very useful for guaranteeing the content-type contract of a web API.

The text was updated successfully, but these errors were encountered:

artyom · 2017-08-22T21:36:19Z

@theory consider this: practically there's big enough chance that API would be running behind some kind of load balancer that may send error replies on its own in some scenarios (including malformed client requests). This would violate your assumption about getting replies that only have json payload in their bodies.

theory · 2017-08-22T21:40:49Z

That's often true, @artyom, but not an assumption I'd always want to make. In order to ensure the integrity of the interface I provide, I'd like to have some ability to determine output formats for errors from http itself, regardless of what the operational deployment ultimately looks like. Helps me avoid QA questions, too.

artyom · 2017-08-23T08:24:50Z

This one is a potential duplicate of #10123.

theory · 2017-08-23T13:35:46Z

Thanks @artyom, I think you're right.

ianlancetaylor · 2017-08-23T21:35:33Z

#10123 is closed, so should we close this one as well? Or with more experience does this seem like a real problem that net/http ought to address?

ghost · 2017-08-23T22:35:55Z

I don't think it's a dup of #10123. Bypassing the handler altogether is a different thing.

tombergan · 2017-09-01T00:12:44Z

I believe this is a dup of #18997 (via #18095). Please reopen if you disagree.

#18997 is a long thread. The tl;dr is here:
#18997 (comment)

tombergan · 2017-09-01T00:13:36Z

Sorry, reopening, it's not a dup. You don't just want to log, you want to return a custom response. I would not consider it a dup of #10123 either, because #10123 was about overriding http.Error, while this is about returning a custom response for internal errors that user code currently has no control over.

I don't know how to fix this cleanly. The quick hack is to add a field http.Server.InternalErrorResponseWriter, but that's ugly. Another approach is to have the server create an actual request, but somehow mark that request "bad". I'm not sure how to do that without breaking existing code.

theory · 2017-09-01T13:51:49Z

Not beautiful, but the simplest solution is to add a method one can override something like:

type ErrorHandler interface {
    HandleError func(w http.ResponseWriter, code int)
}

Then check to see if the Handler implements it.

Pretty similar to Error(), I guess.

tombergan closed this as completed Sep 1, 2017

tombergan reopened this Sep 1, 2017

ianlancetaylor added the NeedsFix The path to resolution is known, but the work has not been done. label Mar 30, 2018

ianlancetaylor added this to the Unplanned milestone Mar 30, 2018

seankhliao mentioned this issue Jun 1, 2022

affected/package: net/http Cannot handle certain invalid request URLs #53179

Closed

seankhliao mentioned this issue Feb 11, 2024

proposal: net/http: Custom handlers for 404 and 405 HTTP response codes #65648

Open

guzba mentioned this issue Mar 28, 2024

Allow for custom management of "Invalid request URI" guzba/mummy#118

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

net/http: Add Error Callbacks #21548

net/http: Add Error Callbacks #21548

theory commented Aug 21, 2017 •

edited

artyom commented Aug 22, 2017

theory commented Aug 22, 2017

artyom commented Aug 23, 2017

theory commented Aug 23, 2017

ianlancetaylor commented Aug 23, 2017

ghost commented Aug 23, 2017

tombergan commented Sep 1, 2017 •

edited

tombergan commented Sep 1, 2017 •

edited

theory commented Sep 1, 2017 •

edited

net/http: Add Error Callbacks #21548

net/http: Add Error Callbacks #21548

Comments

theory commented Aug 21, 2017 • edited

artyom commented Aug 22, 2017

theory commented Aug 22, 2017

artyom commented Aug 23, 2017

theory commented Aug 23, 2017

ianlancetaylor commented Aug 23, 2017

ghost commented Aug 23, 2017

tombergan commented Sep 1, 2017 • edited

tombergan commented Sep 1, 2017 • edited

theory commented Sep 1, 2017 • edited

theory commented Aug 21, 2017 •

edited

tombergan commented Sep 1, 2017 •

edited

tombergan commented Sep 1, 2017 •

edited

theory commented Sep 1, 2017 •

edited