Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
net/http: reconsider bad request logging #18095
Is this the first time we're logging on bad input from users?
If so, @rsc makes a good point, that this might open the doors to let outside users spam server logs.
Maybe it should be a hook instead, or an alternate logger. But it's probably too late for Go 1.8 and we should make API addition decisions in Go 1.9 instead.
But if there's precedent for logging on invalid input, maybe it's fine to keep.
server.logf is called for TLS handshake error which I guess bad clients could trigger? Otherwise it looks like internal server errors only.
Also see original discussion on #12745 - the original suggestion was to make sure a response was sent to clients and/or write to the log. I'd be happy without the logging as if we send a response body it's obvious to the client what is wrong with their request which is why I closed it with the first CL, but someone else did request logging too after it was closed.
I was just reviewing the 1.8 milestone and saw this issue.
I'm a little unclear on if this logging can be optionally disabled. If not, I would like to request that this is not included in 1.8, as some of our very high request-per-second endpoints would be negatively impacted by this. Specifically, we receive a fair number of malformed requests, and have more-or-less disabled logging for performance and reliability (ie, filling disk space) reasons.
Non-optionally logging malformed input would likely cause a substantial performance degradation and risk our systems over-logging, requiring excessive rotation or other techniques to deal with.
Thanks for cc'ing me. I didn't realize http.Server can generate 4xx error responses internally, without calling the request handler. This is a clear logging hole that makes me sympathize with https://golang.org/cl/27950. I run a service that logs metadata about every request/response pair. I didn't realize that our logs are missing a whole class of responses. (In practice, this is not a big deal, since we run behind a frontend that will reject most malformed requests, but still, there should be some hook that can be used to log such responses.)
At the same time, I agree with Russ: spamming stderr is not a good default behavior for this case. I vote to revert the logging portion of https://golang.org/cl/27950 for 1.8. Long term, I think something
For future ref, here is a summary of the current calls to logf in server.go:
ERRORS ACCEPTING CONNECTION:
ERRORS WRITING RESPONSE:
CLIENT ERRORS NOT LOGGED:
Info passed on with these current errors: RemoteAddr, contentLength, error string
So perhaps the best solution here is to add a ServerTrace to pkg httptrace with a handler for errors, which passes some info on to the caller about the reason for failure. See also the work started at #18997 for other tracing options for servers, this would extend that to provide a hook for errors.
I'm not sure on the signature for this error hook, to avoid leaking things like the connection, perhaps a struct containing some ConnInfo like the error, RemoteAddr, connection state, and perhaps an http status code?