oscerd commented on PR #23886:
URL: https://github.com/apache/camel/pull/23886#issuecomment-4659421615
> :robot: _Claude Code on behalf of Andrea Cosentino_
Thanks Claus for the careful review. I went through each point against
CAMEL-23630, the camel-iggy reference implementation it mirrors, and the Dapr
SDK, and I'd like to keep the current approach. Reasoning point by point:
**Context — CAMEL-23630 deliberately chose "option (b)".** The issue offers
two alternatives for the consumer: (a) consult the `HeaderFilterStrategy`
before setting each header, or (b) stop copying `PUBSUB_NAME`/`TOPIC` because
they are producer-direction routing headers. This PR implements (b). The
strategy is added for **consistency with the messaging-component family** and
to expose the standard `headerFilterStrategy` option — exactly as camel-iggy
(the cited reference) does.
**1. "Filter is never applied in the consumer."** Correct, and intentional.
The siblings apply `applyFilterToExternalHeaders()` to an **arbitrary,
sender-controlled header map**: `Sqs2Consumer` filters SQS message attributes,
Kafka filters record headers, iggy filters `message.userHeaders()`. Note iggy
sets its **own** fixed metadata headers (`MESSAGE_ID`, `MESSAGE_OFFSET`, …)
**directly, bypassing the filter**, and runs only `userHeaders()` through it.
The Dapr SDK `CloudEvent<T>` is a fixed POJO
(`getId/getSource/getType/getPubsubName/...`) with **no extension/attribute
map** (checked against `dapr-sdk` 1.16) — so there is no external header
collection to filter, and every header name the consumer sets is a hardcoded,
trusted `CamelDapr*` constant. There is no header-injection vector here to
filter.
**2. "Default strategy would block all `CamelDapr*` headers if applied."**
Agreed — and that's exactly why CAMEL-23630 chose (b) over (a). Running the
component's own `CamelDapr`-prefixed metadata through a `Camel*` filter would
strip them, so neither this PR nor iggy does that; the component's own headers
are always set directly.
**3. "PubSubName/Topic removed but ID/Source/Type kept — inconsistent."**
This asymmetry is the deliberate fix. `CamelDaprPubSubName`/`CamelDaprTopic`
are **read back on the producer side** by
`DaprConfigurationOptionsProxy#getPubSubName/getTopic` (header preferred over
endpoint config; consumed by `DaprPubSubHandler`). Leaving them on a consumed
exchange makes `from("dapr-pubsub:p:t").to("dapr-pubsub:p:other")` route to the
**inbound** pubsub/topic instead of the configured one. `ID/Source/Type/...`
are never read back by any producer operation, so they stay. A `dapr-pubsub`
consumer also subscribes to a single fixed pubsub+topic, so those two headers
were redundant with the endpoint config.
**4. "No producer-side filtering."** `DaprPubSubHandler#handle` reads only
specific, typed headers via `getOption(...)` and builds the publish request
from an explicit, route-author-supplied `CamelDaprMetadata` map — there is no
generic "copy all Camel headers outbound" loop for an out-filter to act on. The
out-filter is still exposed via the standard option for parity with the catalog.
I've pushed a follow-up documenting the consumer header change in the 4.21
upgrade guide. Happy to revisit if you'd prefer a different shape (e.g.
exposing pubsub/topic under non-routing header names), but that would be a
follow-up beyond this issue's scope.
--
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]
