oscerd opened a new pull request, #25004:
URL: https://github.com/apache/camel/pull/25004

   ### Motivation
   
   [CAMEL-23876](https://issues.apache.org/jira/browse/CAMEL-23876). 
`WebhookUrlValidator` resolves the webhook host and applies the SSRF checks 
(rejecting loopback/wildcard/link-local/site-local, requiring HTTPS for 
non-local hosts). `PushNotificationDispatcher` then built a 
`java.net.http.HttpRequest` from the original URL string and let `HttpClient` 
perform its **own, independent** DNS resolution at connection time.
   
   The address that was validated and the address actually connected to are 
resolved separately, so they can differ for the same hostname — classic DNS 
rebinding. Nothing pinned the connection to the address the validator approved.
   
   ### Why HttpClient 5
   
   A pin was not achievable with `java.net.http`:
   
   - `HttpClient.Builder` exposes **no** DNS/resolver hook (only 
`localAddress`, which is the local bind address). The only override is the 
JVM-global `InetAddressResolverProvider` SPI (Java 18+, and far too 
heavy-handed for a component).
   - Replacing the URI host with the validated IP literal would break TLS 
hostname verification — which matters here because the validator **requires 
HTTPS for every non-local webhook**, so that is the normal case.
   
   Apache HttpClient 5's `HttpHost` carries **both** an explicit `InetAddress` 
and the hostname, which is exactly what is needed: connect to the validated 
address, while the `Host` header, TLS SNI and certificate hostname verification 
still use the hostname.
   
   ### Changes
   
   - `WebhookUrlValidator`: new `validateAndResolve(url, allowLocal)` returns 
the address it validated. The existing `void validate(...)` delegates to it, so 
the other three call sites (consumer + both task stores) and the 17 existing 
validator tests are unchanged.
   - `PushNotificationDispatcher`: delivers via `CloseableHttpAsyncClient`, 
targeting a `HttpHost` pinned to the validated address. HttpClient 5's 
`FutureCallback` is bridged to the existing `CompletableFuture` 
retry/backoff/work-tracking machinery, so that logic is unchanged. Response 
handling simplifies slightly — `SimpleHttpResponse` buffers the body, so the 
manual body-close is gone.
   - **Validation and resolution now run on every attempt** rather than once 
per dispatch. Previously a webhook was validated once and could then be retried 
up to 30 times over as much as an hour with no re-check; that window is now 
closed too.
   - `A2AEndpoint`: creates, starts and closes a dedicated webhook client with 
redirect handling disabled — a redirect would be resolved by the client and 
escape the validation applied to the registered URL. This matches the previous 
behaviour (the dispatcher already used `Redirect.NEVER`).
   - New dependency on `org.apache.httpcomponents.client5:httpclient5`; 
upgrade-guide entry covering the change and the `PushNotificationDispatcher` 
constructor signature.
   
   Only the push-webhook path moves to HttpClient 5. `AgentCardLoader` and 
`A2AProducer` talk to the configured agent URL (not caller-registered), and 
stay on `java.net.http`.
   
   ### Testing
   
   - `mvn test` in `components/camel-ai/camel-a2a`: **506 tests pass**, 
including the 9 existing dispatcher tests now exercising the pinned path.
   - 3 new tests asserting the target carries the validated address **and** the 
original hostname, with correct default/explicit port handling.
   - Full reactor `mvn clean install -DskipTests` from root: success, no stale 
generated files.
   
   Main-only (4.22.0): hardening plus a constructor signature change, so not 
proposed for backport.
   
   _Claude Code on behalf of Andrea Cosentino (@oscerd)._
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to