[
https://issues.apache.org/jira/browse/CAMEL-23071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-23071:
--------------------------------
Priority: Minor (was: Major)
> AS2 client should provide endpoint parameter to optionally enable Expect:
> 100-continue
> --------------------------------------------------------------------------------------
>
> Key: CAMEL-23071
> URL: https://issues.apache.org/jira/browse/CAMEL-23071
> Project: Camel
> Issue Type: Improvement
> Components: camel-as2
> Affects Versions: 4.18.0
> Reporter: Reto Peter
> Priority: Minor
>
> h3. Summary
> The Camel AS2 client component has no endpoint parameter to control the
> \{{Expect: 100-continue}} HTTP header behavior. In Camel versions 4.10–4.17,
> \{{RequestExpectContinue}} was hardcoded in the \{{HttpProcessor}} chain with
> no way to disable it, causing a
> 3-second delay per message when the remote server didn't support
> 100-continue. In Camel 4.18.0, the interceptor was silently removed — now
> there is no way to *enable* it either.
> The \{{Expect: 100-continue}} protocol is useful in certain scenarios
> (large payloads, servers that may reject based on headers alone), so this
> should be a configurable option rather than hardcoded on or off.
> h3. History
> || Camel Version || Behavior ||
> | 4.10.x – 4.17.x | \{{RequestExpectContinue}} hardcoded in
> \{{AS2ClientConnection}} HttpProcessor chain — always ON, no option to
> disable |
> | 4.18.0 | \{{RequestExpectContinue}} removed from chain — always OFF, no
> option to enable |
> h3. Problem (Camel 4.10–4.17)
> \{{AS2ClientConnection}} builds its \{{HttpProcessor}} with a hardcoded
> \{{RequestExpectContinue}} interceptor:
> \{code:java|title=AS2ClientConnection.java (Camel 4.17.0)}
> httpProcessor = HttpProcessorBuilder.create()
> .add(new RequestAS2(as2Version, clientFqdn))
> .add(new RequestMDN())
> .add(new RequestTargetHost())
> .add(new RequestUserAgent(this.userAgent))
> .add(new RequestDate())
> .add(new RequestContent(true))
> .add(new RequestExpectContinue()) // <-- hardcoded, no option to
> disable
> .add(new RequestConnControl()).build();
> \{code}
> This causes every outbound AS2 message to include the \{{Expect:
> 100-continue}} header. When the remote AS2 server (e.g., OpenAS2) does not
> implement the 100-continue protocol, HttpCore5's \{{HttpRequestExecutor}}
> waits for a \{{100 Continue}} response that never
> comes, timing out after *3 seconds* (\{{DEFAULT_WAIT_FOR_CONTINUE}})
> before sending the message body.
> For high-volume AS2 systems this adds significant latency — e.g., sending
> 100 messages per day wastes 5 minutes just on expect-continue timeouts.
> h3. Current State (Camel 4.18.0)
> \{{RequestExpectContinue}} was removed from the chain entirely:
> \{code:java|title=AS2ClientConnection.java (Camel 4.18.0)}
> httpProcessor = HttpProcessorBuilder.create()
> .add(new RequestAS2(as2Version, clientFqdn))
> .add(new RequestMDN())
> .add(new RequestTargetHost())
> .add(new RequestUserAgent(this.userAgent))
> .add(new RequestDate())
> .add(new RequestContent(true))
> .add(new RequestConnControl()).build();
> // RequestExpectContinue removed — no option to enable
> \{code}
> This fixes the 3-second delay problem but removes the ability to use
> 100-continue for partners that do support it.
> h3. Proposed Fix
> Add a new AS2 endpoint parameter \{{expectContinue}} (default: \{{false}}
> to maintain 4.18.0 behavior):
> \{code:java|title=AS2ClientConnection.java (proposed)}
> HttpProcessorBuilder builder = HttpProcessorBuilder.create()
> .add(new RequestAS2(as2Version, clientFqdn))
> .add(new RequestMDN())
> .add(new RequestTargetHost())
> .add(new RequestUserAgent(this.userAgent))
> .add(new RequestDate())
> .add(new RequestContent(true))
> .add(new RequestConnControl());
> if (expectContinue) {
> builder.add(new RequestExpectContinue());
> }
> httpProcessor = builder.build();
> \{code}
> The parameter should be exposed on the AS2 endpoint configuration so users
> can set it per route:
> \{code}
> as2://client/send?...&expectContinue=true
> \{code}
> h3. Impact
> - *No breaking change* — default \{{false}} preserves current 4.18.0
> behavior
> - Partners that support 100-continue can benefit from it (early rejection,
> bandwidth savings on large payloads)
> - Partners that don't support it (OpenAS2 and others) continue to work
> without the 3-second delay
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
