Hi all,
I am looking at the new access log valve to add support for the pattern
fields with sub keys (headers, attributes etc.).
Many of those have free text values, so ensuring correct encodig is
important. I noticed, that the AbstractAccessLogValve already does
almost correct JSON encoding and the Json one ensures correct JSON
encoding by again encoding the values coming out of the
AbstractAccessLogValve. So an encoded char in a header ends up as \\u...
in the log, not as \u....
Since the encoding of the base valve is already so close to JSON, I
wonder, whether we could remove the only difference that's there and
then get rid of the double encoding: a vertical tab gets encoded as "\v"
which is not known in JSON. For JSON it needs to get encoded using an \u
sequence. We do that already for most other rarely used control
characters. The only other characters that are simply "\"-escaped are
also allowed in that form in JSON, so are fine.
So what about switching the encoding of vertical tab in the Abstract
valve to \u00? Of course for TC 11 that should not be a problem, but do
people think it would be OK to backport? It doesnt sound like a common
character to expect, \v is not so well-known as a representation and
using \u-style would be more consistent with any other characters. \v is
not even a valid Java character escape (though that's not a strong
argument here).
WDYT?
Thanks and regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
