You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For the combination JSON logging and JSON request/response payloads, make it so that processing details relevant for logging are propagated, so that duplicate work can be avoided.
Detailed Description
Currently JSON payloads are append as raw content within JSON request/response-logging statements. This means that payloads with invalid JSON syntax can / will result in log statements with invalid JSON syntax too. So log accumulation tools will not be able to parse the statement as JSON, and might discard the message, or fall back to handle the log statement as pure text.
However existing body-filters and/or databinding performed in the service may be leveraged to guarantee that the payloads are in fact valid JSON. The logging subsystem can safely append the raw data if it knows that the body
does not contain newlines
is well-formed JSON
If those parameters are unknown, the logging subsystem can attempt to validate the JSON syntax itself and remove newlines. Then continuing to append the payload as raw content, or escaping the payload as JSON text if invalid JSON syntax.
Context
A JSON message might be parsed up to three times,
in a body filter
in the service databinding
when writing the log
The last might be avoided.
Possible Implementation
Add a wrapper for body. This would be a breaking change.
The text was updated successfully, but these errors were encountered:
In order to prioritize the support for Logbook, we would like to check whether the old issues are still relevant.
This issue has not been updated for over a year.
Please check if it is still relevant in latest version of the Logbook.
If so, please add a descriptive comment to keep the issue open.
Otherwise, the issue will automatically be closed after a week.
For the combination JSON logging and JSON request/response payloads, make it so that processing details relevant for logging are propagated, so that duplicate work can be avoided.
Detailed Description
Currently JSON payloads are append as raw content within JSON request/response-logging statements. This means that payloads with invalid JSON syntax can / will result in log statements with invalid JSON syntax too. So log accumulation tools will not be able to parse the statement as JSON, and might discard the message, or fall back to handle the log statement as pure text.
However existing body-filters and/or databinding performed in the service may be leveraged to guarantee that the payloads are in fact valid JSON. The logging subsystem can safely append the raw data if it knows that the body
If those parameters are unknown, the logging subsystem can attempt to validate the JSON syntax itself and remove newlines. Then continuing to append the payload as raw content, or escaping the payload as JSON text if invalid JSON syntax.
Context
A JSON message might be parsed up to three times,
The last might be avoided.
Possible Implementation
Add a wrapper for body. This would be a breaking change.
The text was updated successfully, but these errors were encountered: