-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
proposal: net/http/httputil: custom logger support for httputil.ReverseProxy ErrorLog #66228
Comments
That's not true, and many logging libraries allow you to produce a concrete log.Logger instance connected to their normal log output. E.g. for slog: https://pkg.go.dev/log/slog#NewLogLogger |
Thank you. It's useful to know there are ways to connect to standard logging mechanisms. However, my main concern is about the lack of flexibility to integrate directly with various logging systems beyond just adapting to log.Logger. In some cases, developers might need to log in a way that isn't compatible with log.Logger or require features that are not available through the standard logging interface. This can be especially important for applications that need detailed control over their logging format or need to include more context in their logs. What I'm suggesting is an enhancement to httputil.ReverseProxy that allows for more direct integration with any logging system, not just those that can adapt to log.Logger. This would make it easier for developers to use their preferred logging strategies without having to work around the current limitations. I believe allowing for a more versatile logging interface would be a valuable improvement, making httputil.ReverseProxy more flexible and useful for a wider range of use cases. |
I believe that if the standard library does choose to accept a structured logger, it will be slog.Logger or slog.Handler, rather than another interface that will need even more adaptors |
Thank you for your reply. I agree that using slog.Logger or slog.Handler directly would be better than creating a new interface and needing more adapters. |
Proposal Details
Hello Go team,
I hope this message finds you well. I'm reaching out to suggest an enhancement for the
httputil.ReverseProxy
struct, specifically regarding its logging capabilities.Currently,
httputil.ReverseProxy
allows for anErrorLog
of type*log.Logger
to be specified, which it uses internally to log errors. This is incredibly useful for monitoring and debugging purposes. However, in many applications, logging is handled by more sophisticated systems than the standardlog
package provides, such asslog
or other structured logging libraries.This limitation means that developers must either redirect standard logger output or miss out on integrating
ReverseProxy
error logging with their application's central logging system. Neither of these solutions is ideal, as the former can be cumbersome and the latter can lead to fragmented logging.Therefore, I propose adding support for custom logger interfaces that could be used in place of the standard
*log.Logger
. This change would allow developers to seamlessly integrateReverseProxy
logging with whatever logging system they are using, improving the flexibility and usability of theReverseProxy
for modern Go applications.A potential approach could involve defining a simple logging interface within the
httputil
package that could then be implemented by any logging library. For example:Then,
ReverseProxy
could accept this interface instead of a concrete*log.Logger
type, allowing for any custom implementation that matches the interface.I believe this enhancement would significantly benefit the Go community by providing more flexibility in how errors are logged and integrated with existing systems.
Thank you for considering my suggestion. I look forward to any feedback or thoughts on this proposal.
The text was updated successfully, but these errors were encountered: