The ugly workaround I mentioned, in case anyone is in desperate need of a quick solution.

We are using `net.rakugakibox.spring.boot:logback-access-spring-boot-starter` library to set up logback-access in our Spring Boot (v2.3.3) app.

The class we are copying into our project is `TomcatLogbackAccessEvent` and in it, we are adding the following code:

@Override
public String getRequestContent() {
    if (isSuppressedContentType(getRequest().getContentType())) {
        return "[CONTENT SUPPRESSED]";
    }
    return super.getRequestContent();
}

@Override
public String getResponseContent() {
    if (isSuppressedContentType(getResponse().getContentType())) {
        return "[CONTENT SUPPRESSED]";
    }
    return super.getResponseContent();
}

private boolean isSuppressedContentType(String contentType) {
    return contentType != null && (
            contentType.startsWith("image/")
               || contentType.equals("application/pdf")
               || contentType.equals("application/zip")
    );
}

We place this class in the application, but keep the same package (so that qualified class name remains the same as in `logback-access-spring-boot-starter` library).

Then once our app starts it is our modified version of that access event class that gets loaded instead of the one provided in the library (this is because classes in the app itself have higher classloading priority than those located in libs).

It works, but it's fragile because we now have a bunch of copied and modified code that we have to manually keep in sync when we are updating that third party library.