I have a case where I have exposed a POST operation for a file download. When I curl the APIC operation and pipe the response into a file, I get the correct thing.

When we do it via the app, we get a 0 size file. Looking at the api behavior in detail, I've noticed the following:

The operation works, however APIC does NOT return the content-length response header.

< HTTP/1.1 200 OK
< X-Backside-Transport: OK OK
< Connection: Keep-Alive
< Transfer-Encoding: chunked
< Content-Type: application/pdf
< Date: Tue, 11 Jun 2024 14:27:10 GMT
< X-Global-Transaction-ID: 2715907166685ebe3660d603
< User-Agent: IBM-APIConnect/5.0
< content-disposition: attachment; name="Sign_doc.pdf"; filename="=?UTF-8?Q?Sign=5Fdoc.pdf?="; filename*=UTF-8''Sign_doc.pdf
< cache-control: no-cache, no-store, max-age=0, must-revalidate
< pragma: no-cache
< expires: 0
< x-content-type-options: nosniff
< strict-transport-security: max-age=31536000
< x-frame-options: DENY
< x-xss-protection: 0
< referrer-policy: no-referrer
< Access-Control-Expose-Headers: APIm-Debug-Trans-Id, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-Global-Transaction-ID
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: POST
< Set-Cookie: fe5e7af26fda951c1af253220df45365=7ccd2d653f79c986454280c93f377a8a; path=/; HttpOnly

If I curl the backend service directly, the header is there

< HTTP/1.1 200 OK
< content-length: 55862   <-- here it is
< content-disposition: attachment; name="Sign_doc.pdf"; filename="=?UTF-8?Q?Sign=5Fdoc.pdf?="; filename*=UTF-8''Sign_doc.pdf
< content-type: application/pdf
< accept-ranges: bytes
< cache-control: no-cache, no-store, max-age=0, must-revalidate
< pragma: no-cache
< expires: 0
< x-content-type-options: nosniff
< strict-transport-security: max-age=31536000 ; includeSubDomains
< x-frame-options: DENY
< x-xss-protection: 0
< referrer-policy: no-referrer
< set-cookie: fe5e7af26fda951c1af253220df45365=7ccd2d653f79c986454280c93f377a8a; path=/; HttpOnly

If I log the header value, within apic, I see the value as well.

      - gatewayscript:
          title: log-content-size
          version: 1.0.0
          source: |
            let header = apim.getvariable('message.headers.content-length');
            console.error("header: " + header);

Log

4:06:16 PM	gatewayscript-user	error	912284115	request	x	0x8580005c	mpgw (webapi): header: 55862

Any idea what is causing this?

Bit more digging showed up the collision between using both content-length and transfer-encoding headers, that they are in collision. And is seems that APIC is chunking the response down the line.

Is it possible to disable this behavior, make it return the same way it received it? 

Hi Vic,
The API Gateway Service's HTTPS Front Side Handler specifies the default behavior to chunk responses.  You can override this behavior with a Gateway Extension.  The manifest.json should use a "gwd_extension" (https://www.ibm.com/docs/en/api-connect/10.0.5.x_lts?topic=gateway-extensions-manifest) which will reference a .json file that in your case for the front-side-handler would look like https://www.ibm.com/docs/en/api-connect/10.0.5.x_lts?topic=type-front-side-handler.  I'm free-handing that file here, but perhaps something like

{
   "front-side-handler":{
      "_global":{
         "source-https":[
            "chunked-encoding off"
         ]
    }
}

Of course this would mean that every response would not use chunked encoding to the service's client, not just this particular API's response.  Also note as far as the manifest files entry is concerned, that currently the deployment of this gwd_extension is always deferred.  That means that after you deploy your Gateway Extension using CMC that the APIC Gateway Service will need to be restarted to take effect.
Regards,
Steve

Such an approach seems a bit excessive; we don't wish to modify APIC to such a degree. As we control the back-end service, we are currently looking into using a custom header to carry the required information, so that the client application can properly work with it.

{   "front-side-handler":{      "_global":{         "source-https":[            "chunked-encoding off"         ]    }}