[logback-dev] [JIRA] Updates for LOGBACK-1526: Logback-access pollutes logs with binary file content

[QOS.CH (JIRA)]

logback / LOGBACK-1526 [Open]
Logback-access pollutes logs with binary file content

==============================

Here's what changed in this issue in the last few minutes.
This issue has been created
This issue is now assigned to you.

View or comment on issue using this link
https://jira.qos.ch/browse/LOGBACK-1526

==============================
 Issue created
------------------------------

Gediminas Rimsa created this issue on 02/Oct/20 9:11 AM
Summary:              Logback-access pollutes logs with binary file content
Issue Type:           Bug
Affects Versions:     1.2.3
Assignee:             Logback dev list
Components:           logback-access
Created:              02/Oct/20 9:11 AM
Environment:
  Logback 1.2.3
  
  Logback-access config:
  {code:java}
  <configuration>
      <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
          <filter class="ch.qos.logback.core.filter.EvaluatorFilter">
              <evaluator class="ch.qos.logback.access.net.URLEvaluator">
                  <URL>/ping</URL>
              </evaluator>
              <OnMismatch>NEUTRAL</OnMismatch>
              <OnMatch>DENY</OnMatch>
          </filter>
          <encoder>
              <pattern>%t{ISO8601} [%I] %requestURL | status code: %statusCode | elapsed time: %elapsedTime | request: %magenta(%requestContent) | response: %cyan(%responseContent)</pattern>
          </encoder>
      </appender>
      <appender-ref ref="STDOUT"/>
  </configuration>
  {code}
Priority:             Major
Reporter:             Gediminas Rimsa
Description:
  h2. Problem
  
  We have a Spring boot app exposing a RESTful API that runs on embedded Tomcat (latest versions) and uses logback-access (also latest 1.2.3). Recently I noticed that access logs include
  
  raw binary content of images/PDF files. Example from logs:
  
   
  {code:java}
  POST /projects/projectId/images HTTP/1.1 | status code: 200 | elapsed time: 664 | request: GIF89a� d �[[ most content ommitted ]]g��� w���� ; | response: {"id":"877f2338-293d-403b-99fb-09fc631ce7b3"}
  
  GET /projects/projectid/images/877f2338-293d-403b-99fb-09fc631ce7b3 HTTP/1.1 | status code: 200 | elapsed time: 538 | request: | response: [IMAGE CONTENTS SUPPRESSED]
  {code}
  As you see, binary content suppression is incomplete. This is how it works currently for different content types:
  
   
  || ||image/*||any other binary||
  |Request|{color:#de350b}logged{color}|{color:#de350b}logged{color}|
  |Response|{color:#00875a}suppressed{color}|{color:#de350b}logged{color}|
  
  For us it is a problem, as our application has to regularly deal with large (20+ MB) ZIP and PDF files,
  h2. Cause
  
  Looking at the code, image content suppression happens in `+ch.qos.logback.access.spi.AccessEvent#getResponseContent+`, but it only checks if content type starts with `_image/_`. Equivalent code in `+ch.qos.logback.access.spi.AccessEvent#getRequestContent+` is not present.
  
  I traced response image content suppression was added with this commit (all the way back in 2007):
  
  [https://github.com/qos-ch/logback/commit/69290e182f8db6589eadd5a3c485a37255384893].
  h2. Workaround
  
  None, except for ugly classloading hacks or implementing a custom `AccessEvent` that overrides `getRequestContent` and `getResponseContent`.
  h2. Resources
  
  Related thread (with no responses) in logback-user mailing list: http://mailman.qos.ch/pipermail/logback-user/2020-September/005086.html
  
   


==============================
 This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)