Tolerate servlet responses without Servlet 3.0 header accessors (quick fix)

[dougqh]

What Does This Do

Makes the servlet 3.0 response-header reader tolerate response classes that don't implement the Servlet 3.0 header accessors.

HttpServletExtractAdapter.Response called HttpServletResponse.getHeaderNames() / getHeader(...) on every response. A class compiled against Servlet 2.5 that implements HttpServletResponse itself doesn't implement them, so the call throws AbstractMethodError. That escaped through HttpServerDecorator.callIGCallbackResponseAndHeaders, was reported as "Failed to decorate span on response", and stopped the response-header callbacks for every response of that class.

Now the accessors are guarded by a ClassLatch keyed on the response class:

• Healthy path: unchanged apart from one plain flag read inside ClassLatch.
• First failure of a class: handleAbstractMethod(response, "getHeaderNames", ...) latches the class; a getHeader failure latches it the same way, through latchIfNamed. Either way the visit stops without re-emitting keys.
• Latched class: visits no headers.

Revised from the first version: this used to hand-roll the same pieces (a static tripwire, a per-class ClassValue, a reflection probe) plus a fallback that unwrapped ServletResponseWrapper to find a usable delegate. ClassLatch provides the first three. The unwrap is dropped because it can almost never apply: HttpServletResponseWrapper comes from the container's Servlet 3.0+ jar, so a wrapper subclass compiled against 2.5 inherits working, delegating accessors and never throws. The classes that do throw implement HttpServletResponse directly and aren't wrappers. A test pins that inheritance.

Motivation

Instrumentation telemetry shows this at HttpServletExtractAdapter$Response.getHeaderNames:48: about 10.5k events a day, steady at 400-500 an hour, on tracers 1.58 to 1.66, mostly Java 8 services.

Muzzle can't catch this. It verifies that HttpServletResponse.getHeaderNames() exists in the API, and it does. The failure is a particular runtime implementation not honouring it.

Additional Notes

Depends on #12799 (stacked on it). On Java 8, AbstractMethodError has no message once the call site has seen a working class, and without #12799 ClassLatch never latches there. The two latch tests warm the call sites with a working response first; they fail on Java 8 against master's ClassLatch and pass with #12799.

For the AppSec/IAST reviewers, please look at this:

• responseStarted(status) fires before the header visit, so it was never affected. What was skipped is the response-header callbacks and igKeyClassifier.done() (responseHeaderDone).
• For a latched class the visitor returns without visiting, so done() still runs with no headers. The servlet 2.x decorator instead returns a null responseGetter(), which skips the header callbacks and done() entirely. I went with "empty headers" so responseHeaderDone still fires. Happy to switch to the 2.x behaviour if AppSec prefers it.
• Only the accessor calls are guarded. An AbstractMethodError from the classifier.accept callback says nothing about the response class and doesn't latch it (there's a test for this).

Tests: HttpServletExtractAdapterTest, 7 cases, using ASM-generated response classes so a real AbstractMethodError is thrown. They cover a class missing both accessors, a class missing only getHeader (not producible by javac, but possible from bytecode generators), a 2.5-style wrapper subclass, healthy responses after a failure, and a callback failure. They pass on the default JDK and on Java 8. The full javax-servlet-3.0 suite passes (1,360 tests).

🤖 Generated with Claude Code

[datadog-datadog-prod-us1-2]

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 58.93% (-0.54%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: bea559a | Docs | Give us feedback!}

[dd-octo-sts]

🟢 Java Benchmark SLOs — All performance SLOs passed

Suite	Status
Startup	🟢 pass

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

PR vs. master results

Scenario	Candidate	master	Δ (95% CI of mean)
startup:insecure-bank:iast:Agent	13.97 s	13.87 s	[+0.0%; +1.4%] (maybe worse)
startup:insecure-bank:tracing:Agent	12.91 s	12.97 s	[-1.2%; +0.3%] (no difference)
startup:petclinic:appsec:Agent	17.19 s	17.18 s	[-0.9%; +1.1%] (no difference)
startup:petclinic:iast:Agent	17.00 s	17.10 s	[-1.3%; +0.1%] (no difference)
startup:petclinic:profiling:Agent	16.69 s	16.80 s	[-1.5%; +0.3%] (no difference)
startup:petclinic:sca:Agent	17.14 s	17.10 s	[-0.5%; +1.0%] (no difference)
startup:petclinic:tracing:Agent	16.14 s	16.14 s	[-1.0%; +1.0%] (no difference)

Commit: bea559a1 · CI Pipeline · Benchmarking Platform UI

---

Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.

[dougqh]

To Claude, let's just call this HEADER_LATCH

[dougqh]

This latching situation isn't as straight-forward as others, but I think this application makes sense. I'm curious to hear what others think.

The latch is really driven by calls to getHeader in the loop below, but once the latch is triggered, we cut off the flow of calls to getHeaders to short-circuit the entire process.