Iterators and Generators may not be rewindable, so foreach is not safe
to use on them.
Iterators and especially Generators may trigger irreversible actions on
calling next(), so iterating over all values can potentially cause harm,
e.g. imagine an iterator over a set of HTTP POST requests that are sent
when the next value is requested . The only sufficiently safe thing to
iterate and include here are primitive arrays.
Related #831
Logs stored in a ELK-based solution need to keep the value typing, especially with float vs integer types.
Adding `JSON_NUMERIC_CHECK` and `JSON_PRESERVE_ZERO_FRACTION` allow to avoid issue.
Detect and attempt to recover from json_encode errors triggered by
strings containing invalid UTF-8 sequences. Recovery will only be
attempted when encoding strings or arrays. If recovery fails then
a RuntimeException will be thrown.
The recovery process will convert invalid UTF-8 codepoints as though the
input string was encoded using the ISO-8859-15 character encoding. This
conversion may result in incorrect string output if the original
encoding was not ISO-8859-15, but it will be a valid UTF-8 string.
Closes#545
Refs https://github.com/Seldaek/monolog/pull/474/files
The fix in the previous PR did not take into account that there might be object wrapped resources that would break json_encode, so the best solution would be normalizing those frames again.
@Seldaek Sorry for the inconvenience, but our graylog is still ramming up with those json_encode error messages.
With `React` or `Guzzle`, that register stream wrappers with PHP, the traces are treated as coming from internal functions with no line and file inside the frame. But they almost always contain resources as arguments, on which the `json_encode()` call will choke (probably this should be addressed in json_encode internally, since it is very easy to cast a resource to a string).
I added a test case proving the situation and a pretty basic recursive checker for resources which just casts them as a string into the frame again.
