oscerd commented on issue #2042:
URL:
https://github.com/apache/camel-kamelets/issues/2042#issuecomment-5475486880
Looked into this. **`cookieManagementDisabled` cannot be exposed as a
Kamelet property**, and adding it naively would be actively harmful rather than
merely ineffective. Evidence below, because the failure mode here is silent.
## It is a component option, not an endpoint option
In the Camel catalog for `camel-http` (4.22.0) it appears only under
`componentProperties`:
```
[componentProperties] cookieManagementDisabled: default=False
[componentProperties] cookieStore: default=None
[properties] clearExpiredCookies: default=True
[properties] cookieHandler: default=None
[properties] cookieStore: default=None
```
and in the source it is a field on `HttpComponent`, consumed while building
the client:
```java
// HttpComponent.java
protected boolean cookieManagementDisabled;
...
if (cookieManagementDisabled) {
clientBuilder.disableCookieManagement();
}
```
There is no equivalent on `HttpEndpoint`. Kamelets configure endpoints
through URI parameters, so there is no supported way for a Kamelet template to
reach it.
## Why adding it anyway would be worse than a no-op
`camel-http` does not reject unknown query parameters — it forwards them to
the remote server as part of the request URI. So the endpoint appears to accept
the option:
```yaml
- to: "http://localhost:18099/test?cookieManagementDisabled=true";
```
The route starts with no error. But capturing the raw request on the other
end shows where the parameter actually goes:
```
GET /test?cookieManagementDisabled=true HTTP/1.1
Accept-Encoding: gzip, deflate, x-gzip
Host: localhost:18099
```
So wiring this into `http-sink` / `http-secured-sink` as `parameters:
cookieManagementDisabled: "{{cookieManagementDisabled}}"` would leave cookie
handling completely unchanged **and** append a meaningless query parameter to
every outbound request — visible to the remote server, in its logs, and
potentially significant to a strict API. That is a silent correctness
regression, which is why I have not opened a PR.
## What does work today
**Set it at the component level**, which is where Camel puts it. Outside the
Kamelet, in the application properties of the deployment:
```properties
camel.component.http.cookie-management-disabled=true
```
This applies to every `http:` endpoint in the integration, including the
ones the Kamelets create. For the common case — "I do not want this integration
keeping a cookie jar" — that is usually the intent anyway.
**Per-endpoint**, the closest supported lever is `cookieStore`, which *is*
an endpoint option and can be pointed at a no-op store by bean reference. That
needs a bean rather than a boolean, so it does not map cleanly onto a Kamelet
property either.
## Options from here
1. Close this and document the
`camel.component.http.cookie-management-disabled` property in the http Kamelet
docs — no catalog change needed.
2. Raise it with `apache/camel` to expose `cookieManagementDisabled` at
endpoint level; once it is an endpoint option, adding the Kamelet property is
trivial and I am happy to do it then.
I would suggest 1 now and 2 if there is real demand, but this is a
maintainer call rather than something to decide in the issue. Leaving it open
pending your preference.
---
_Claude Code on behalf of Andrea Cosentino_
--
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]
