Conversation
Report block_failure on appsec.waf.requests when Tomcat's blocking-commit path fails to enforce a decided block, mirroring the Netty implementation (#12316). Adds a shared TomcatBlockingHelper.tryCommitAndReport choke point used by all Tomcat/GlassFish blocking-commit call sites (5.5/6.0/7.0), and guards it against exceptions thrown by the registered BlockResponseFunction.
…lemetry Extract tryCommitAndReport()/reportBlockFailure(RequestContext) into a new catalina-independent BlockFailureReporter class in tomcat-common, since helperClassNames() injects the whole class and muzzle validates all its references against every declared library version - including the catalina-independent code path that doesn't need it.
jandro996
added
type: feature
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Codex Review: Didn't find any major issues. Hooray! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
🛡️ Codex Security Review · Automatically triggeredSecurity review completed. No security issues were found in this pull request. Reviewed commit: Only the user who started this review can view the report in Codex. ℹ️ About Codex security reviews in GitHubThis is an experimental Codex feature. Security reviews are triggered when:
Once complete, Codex will leave suggestions, or a comment if no findings are found. |
|
🎯 Code Coverage (details) 🔗 Commit SHA: d0b8dcf | Docs | View more details | Give us feedback! |
🟢 Java Benchmark SLOs — All performance SLOs passed
PR vs. master results
Commit: Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion. |
…Function TestSpringBlockResponseFunction now delegates to the previously registered BlockResponseFunction (Tomcat's own, in production tests) instead of returning true/false unconditionally when RequestContextHolder is not yet populated by Spring, fixing 10 latestDepTest failures exposed by the tryCommitAndReport refactor.
|
@codex review |
|
Codex Review: Didn't find any major issues. 👍 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
🛡️ Codex Security Review · Automatically triggeredSecurity review completed. No security issues were found in this pull request. Reviewed commit: Only the user who started this review can view the report in Codex. ℹ️ About Codex security reviews in GitHubThis is an experimental Codex feature. Security reviews are triggered when:
Once complete, Codex will leave suggestions, or a comment if no findings are found. |
…fallback response Guard the Servlet API fallback branch of tryBlock() so reportBlockFailure() only fires when a response was actually available to commit through (i.e. a commit was genuinely attempted). Previously it reported unconditionally whenever the fallback commit failed, including the brf == null / fallbackResp == null case where nothing was attempted at all.
|
@codex review |
🛡️ Codex Security Review · Automatically triggeredSecurity review completed. No security issues were found in this pull request. Reviewed commit: Only the user who started this review can view the report in Codex. ℹ️ About Codex security reviews in GitHubThis is an experimental Codex feature. Security reviews are triggered when:
Once complete, Codex will leave suggestions, or a comment if no findings are found. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f34f16feea
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…ailureReporter Remove the catch(Exception) around brf.tryCommitBlockingResponse() in tryCommitAndReport() so it matches the Netty reference implementation (PR #12316), which only branches on the boolean return value. Several call sites (CommitActionInstrumentation in 5.5/7.0, ParsePartsInstrumentation, ParsedBodyParametersInstrumentation) rely on their enclosing advice's suppress = Throwable.class to abort the whole method when the commit throws, gating success-path side effects (closing the connection, injecting a BlockingException, marking the segment effectively blocked). Swallowing the exception inside tryCommitAndReport made those side effects run unconditionally even when nothing was actually committed to the client. Removing the catch restores the pre-existing control flow; exception-based commit failures are now a known gap not reported to block_failure telemetry, same as Netty. Addresses Codex review comment on PR #12493.
|
@codex review |
|
Codex Review: Didn't find any major issues. Nice work! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
🛡️ Codex Security Review · Automatically triggeredSecurity review completed. No security issues were found in this pull request. Reviewed commit: Only the user who started this review can view the report in Codex. ℹ️ About Codex security reviews in GitHubThis is an experimental Codex feature. Security reviews are triggered when:
Once complete, Codex will leave suggestions, or a comment if no findings are found. |
![datadog-prod-us1-6[bot]](https://avatars.githubusercontent.com/u/365230?s=60&v=4){kind=small}
There was a problem hiding this comment.
More details
All changed Tomcat and GlassFish commit paths use the shared failure reporter. Each affected instrumentation includes the required helper.
🤖 Datadog Autotest · Commit 6fc0248 · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest
| testImplementation group: 'tomcat', name: 'tomcat-util', version: tomcatVersion | ||
| testImplementation group: 'javax.servlet', name: 'servlet-api', version: '2.4' | ||
| testImplementation libs.bundles.junit5 | ||
| testImplementation libs.bundles.mockito |
There was a problem hiding this comment.
Since build files changed, please regenerate lock files too.
|
|
||
| dependencies { | ||
| compileOnly group: 'org.apache.tomcat', name: 'coyote', version: '6.0.53' | ||
| implementation project(':dd-java-agent:instrumentation:tomcat:tomcat-common') |
There was a problem hiding this comment.
Same here, probably lock files should be regenerated.
There was a problem hiding this comment.
Regenerated but no-op diff for this file, it's a project dependency
Regenerate the lock file to reflect the testImplementation
dependencies added in TODO-9 (catalina/coyote/util, servlet-api,
JUnit 5, Mockito) for the sun.misc.Unsafe-based test. No change
needed for tomcat-appsec-6.0's lockfile: its new project(':...:tomcat-common')
dependency does not add any external dependency to its classpath.
Addresses review comments from AlexeyKuznetsov-DD on PR #12493.
3 participants
What Does This Do
block_failureon theappsec.waf.requestsmetric when Tomcat's blocking-commit path fails to enforce a decided block, mirroring the Netty implementation (Add block-outcome telemetry for Netty blocking enforcement failures #12316).BlockFailureReporter.tryCommitAndReport(RequestContext, Flow.Action.RequestBlockingAction)intomcat-commonas a shared choke point: commits the blocking response via the registeredBlockResponseFunctionand, if the commit fails (returnsfalse), reports failure throughAppSecContext.reportBlockFailure()(resolved fromRequestContext.getData(RequestContextSlot.APPSEC)). Exceptions thrown by the commit attempt are deliberately propagated (not converted into afalsereturn), so the calling advice'ssuppress = Throwable.classaborts the whole advice and skips its blocking success-path side effects; such exception-based failures are a known telemetry gap shared with the Netty implementation.CommitActionInstrumentation(5.5, 7.0),ParsedBodyParametersInstrumentation(5.5, 6.0),ParsePartsInstrumentation(7.0),GlassFishBlockingHelper/GlassFishMultipartInstrumentation(7.0), andTomcatServerInstrumentation(5.5 base).TomcatBlockingHelper.commitBlockingResponse()'s genuinely reachable failure path (GET_OUTPUT_STREAM == null) to also reportblock_failure, without changing its existing "already committed" / "write threw"true-return semantics (deliberately out of scope).GlassFishBlockingHelper.tryBlock()'s Servlet API fallback branch soreportBlockFailure()only fires when a response was actually available to commit through (i.e. a commit was genuinely attempted), not on thebrf == null/fallbackResp == nullcase where nothing was attempted at all.Split of
TomcatBlockingHelpertryCommitAndReport()/reportBlockFailure(RequestContext)into a new class,BlockFailureReporter(tomcat-common), that has no dependency onorg.apache.catalina.*types.TomcatBlockingHelperkeeps only the catalina-typed methods (commitBlockingResponse(),start(),tryWriteWithOutputStream/Writer, the privatereportBlockFailure(Request)).helperClassNames()injects a helper's entire class bytecode, and Gradle'smuzzletask validates every reference in that bytecode against each declared library version group. Before the split, instrumentations whose target library range does not guaranteeorg.apache.catalina.connector.Request/Responsepresence (e.g. sometomcat-appsec-5.5/6.0/7.0groups) failed muzzle just from listingTomcatBlockingHelper, even though their advice only ever called the catalina-independenttryCommitAndReport/reportBlockFailure(RequestContext)methods.RequestInstrumentation/ResponseInstrumentation(tomcat-5.5) also neededBlockFailureReporteradded tohelperClassNames(), since they listTomcatBlockingHelpertransitively (viaTomcatDecorator) andTomcatBlockingHelper's ownreportBlockFailure(Request)still delegates toBlockFailureReporter.reportBlockFailure(reqCtx).Motivation
APPSEC blocking-outcome telemetry currently only exists for Netty (#12316). This extends coverage to Tomcat so that a WAF-decided block that silently fails to actually block the request (e.g. response already committed,
BlockResponseFunctionthrowing) is observable via theblock_failuretag onappsec.waf.requests, instead of looking like a successful block.Additional Notes
tomcat-common's new test dependencies (tomcat:catalina/tomcat-coyote/tomcat-util,javax.servlet:servlet-api:2.4, JUnit 5, Mockito) required regeneratinggradle.lockfilefor that module (tomcat-appsec-6.0's lockfile needs no change: its newimplementation project(...)dependency adds no external dependency to that module's classpath).spring-webmvctest fixtures (TestSpringBlockResponseFunction): it was unconditionally returningtrue/falseinstead of delegating to the previously registeredBlockResponseFunctionwhenRequestContextHolderis not yet populated by Spring, which clobbered Tomcat's realBlockResponseFunctioninlatestDepTestruns and surfaced as 10 unrelated test failures oncetryCommitAndReportstarted being exercised on that path.Contributor Checklist
type:and (comp:orinst:) labels in addition to any other useful labelsclose,fix, or any linking keywords when referencing an issueUse
solvesinstead, and assign the PR milestone to the issueJira ticket: APPSEC-62696
Note: Once your PR is ready to merge, add it to the merge queue by commenting
/merge./merge -ccancels the queue request./merge -f --reason "reason"skips all merge queue checks; please use this judiciously, as some checks do not run at the PR-level. For more information, see this doc.