Gen 8.6 CALL EXTERNAL "Server returned nothing (no headers, no data)"

Products

Gen

Issue/Introduction

When we execute Call External statement from a C client to a Gen EJB Web Service deployed under WebSphere see the following error:

TIRM030E: Application failed - Updates have been backed out
TIRM031E: Failing procedure exit data follows:
TIRM032E: Last or current action block id = 0039404123
TIRM033E: Last or current action block name = CAB_EXT_CALL
TIRM034E: Last or current database statement = 0
TIRM035E: Current statement being processed = 0000000001
TIRM037E: ** Fatal Error was encountered ***
TIRM149E: Error occurred in CA Gen supplied function: TIRXCWS
TIRM322E: Error occurred while performing external call
Error message: "Server returned nothing (no headers, no data)"
TIRM046E: *** Processing terminated ***
TIRM044E: *** Press OK to continue ***

The target URL for the Web Service is http://hostname:80/... rather than usual 4 digit port number for a WebSphere server.
A NetScaler load balancer is being used which redirects to a specific node in a WebSphere cluster according to their individual load.

Environment

Gen 8.6
GUI C client calling Gen EJB Web Service deployed to WebSphere Application Server.

Cause

After testing against a single WebSphere instance, the CALL EXTERNAL was successful.

A NetScaler packet trace showed Warning message "The Content-Length and Transfer-Encoding header must not be set together" designated as Malformed for the CALL EXTERNAL HTTP POST.

Based on that warning a NetScaler policy was blocking the CALL EXTERNAL from being executed.
Having Content-Length and Transfer-Encoding fields set together in the header indicates a potential HTTP Request Smuggling vulnerability and the NetScaler policy cannot be changed.
References:
HTTP Request Smuggling, what it is, how to find it and how to stop it

RFC 7230 : Section 3.3.2. Content-Length
"A sender MUST NOT send a Content-Length header field in any message
that contains a Transfer-Encoding header field."

RFC 7230 : Section 3.3.3. Message Body Length
"If a message is received with both a Transfer-Encoding and a
Content-Length header field, the Transfer-Encoding overrides the
Content-Length. Such a message might indicate an attempt to
perform request smuggling (Section 9.5) or response splitting
(Section 9.4) and ought to be handled as an error. A sender MUST
remove the received Content-Length field prior to forwarding such
a message downstream."

Resolution

After testing with trace enabled (set environment variable CMIDEBUG=-1), Support can see that both Content-Length and Transfer-Encoding fields are in the CALL EXTERNAL HTTP POST header. Testing with Gen 8.6 GA did not show the Transfer-Encoding field in the header.
The program curl is used by Gen C runtime to execute the CALL EXTERNAL HTTP POST. This behaviour has changed due to a curl version update in a Gen 8.6 PTF.
NOTE: Under page https://curl.se/libcurl/c/CURLOPT_POST.html it states "Since 7.66.0, libcurl automatically uses chunked encoding for POSTs if the size is unknown."
To resolve the problem, Gen Engineering provided a new test fix version of the Gen 8.6 C runtime file iefabrtn.dll so that curl knows the buffer detail/size which avoids having "Transfer-Encoding" in the header.

October 17: The official PTF for this problem has been released as RTN86318/LU13284. It is also listed on the Gen 8.6 Solutions & Patches page.

Additional Information

Using CALL EXTERNAL trace output may help with similar problems. See article: How to trace a Gen 8.6 GUI C client CALL EXTERNAL error