Aggregated server-side logging
mindplay-dk opened this issue · 2 comments
I'd like to propose adding support for optional server-side aggregation of the logs.
I'd suggest a very simple addition to the extension.
It currently looks for the data embedded in the x-chromelogger-data.
I'm proposing an alternative header x-chromelogger-url, which would instead provide a URL, from which the client can fetch the server-side logs with a subsequent GET request for the same JSON data.
This would enable server-side implementations to store data in temp-files (or a cache, etc.) and expose server-side logs of any arbitrary size.
I would immediately add support for this to kodus/chrome-logger, which (like some implementations on other platforms) is middleware-based, making it very easy for a developer to bootstrap the logger with a single component.
This would address issues like #40 and #61, which apparently are all too common.
The default header-size limit in NGINX, for example, is much too low for ChromeLogger to be of any real use - even if we try to document our way around these issues, header-size limitations apparently exist in all sort of server-software, and developers and sys-admins usually need to debug this the hard way. It's a considerable waste of time.
Most of the server-side implementations address the header-size limitation in Chrome by introducing a ~240K limit on the size of the emitted header. That's not a good work-around, because (1) you can't be certain that other headers don't grow beyond the remaining ~16K that's left over, and (2) in some debugging scenarios you actually need the full log-data, e.g. when you need a log-entry generated near the beginning and near the end of the same request.
@ccampbell let me know if you'd accept a PR?
I see now that this was actually implemented in '14 in #52.
I'd like to redo it using today's APIs though, and that PR is probably too old to merge anyhow.
@ccampbell are you there?
I'd like to help.