Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

Chunk must be last transfer encoding 502 error code

Dears,

I hope you are doing well,

I am facing an issue with one of the target systems that uses Spring Boot as a backend.

{
    "fault": {
        "faultstring": "chunked MUST be the last transfer-coding applied to the message-body",
        "detail": {
            "errorcode": "protocol.http.ChunkedShouldBeLast"
        }
    }
}

I sent the request from Postman through APIgee to the target

502 Bad Gateway
The server, working as a gateway got an invalid response.

But If I take the cURL command and send it to the target from the "RMP" server directly I get a successful response.

 

Also, I detected some headers from the backend server,  Transfer-Encoding: chunked

Is this header causing the issue?

Could you please support me?

Thank you

Amer Hijazi

 

Solved Solved
0 7 838
1 ACCEPTED SOLUTION

Apigee seems to be complaining that your upstream system  (the thing implemented in Spring Boot) is sending back an invalid or incorrect response. 

You didn't note the entire response, but provided an observation about exactly ONE header, Transfer-Encoding.  Is it possible that the response is also using a header Content-Encoding: chunked ?  If that is the case then Apigee is rightly complaining. The error is expected.

If this is what's happening, to correct the problem, Check the backend system, and make sure the headers it returns in the response are valid and correct. Content-Encoding can take values like gzip, deflate, compress, and some others. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding   It should never contain the word "chunked". 

A response with "chunked" in the Transfer-Encoding header is ok, and valid. Apigee should not complain about that.  If the response uses both Transfer-Encoding:chunked and Content-Encoding:chunked, the latter header is wrong.  It should not be there. 

 

 

View solution in original post

7 REPLIES 7

Apigee seems to be complaining that your upstream system  (the thing implemented in Spring Boot) is sending back an invalid or incorrect response. 

You didn't note the entire response, but provided an observation about exactly ONE header, Transfer-Encoding.  Is it possible that the response is also using a header Content-Encoding: chunked ?  If that is the case then Apigee is rightly complaining. The error is expected.

If this is what's happening, to correct the problem, Check the backend system, and make sure the headers it returns in the response are valid and correct. Content-Encoding can take values like gzip, deflate, compress, and some others. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding   It should never contain the word "chunked". 

A response with "chunked" in the Transfer-Encoding header is ok, and valid. Apigee should not complain about that.  If the response uses both Transfer-Encoding:chunked and Content-Encoding:chunked, the latter header is wrong.  It should not be there. 

 

 

Dear @dchiesa1,

I hope you are doing well

Please find the 

< HTTP/1.1 200 
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 0
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< X-Frame-Options: DENY
< Transfer-Encoding: chunked
< Date: Thu, 07 Nov 2024 04:59:54 GMT
< Keep-Alive: timeout=60
< Connection: keep-alive
< Content-Type: application/json
< Transfer-Encoding: chunked

The value < Transfer-Encoding: chunked. is returned twice once in the middle and one in the last.

Thank you

Dear @dchiesa1 

I am trying from the CMD to the backed directly without APIgee 

This how I got the response

I see

Well I am not clear, then, on what is happening. The backend should not send two identical headers like that.  But Apigee should be robust enough to handle them anyway, I would think. I don't see anything in Apigee that would lead to the error  you reported, when Apigee receives the response headers you showed. 

Even so, If you can modify the backend so that the response is cleaner, try that. 

Another thing - the response you see by invoking the backend from CMD, without Apigee, is not necessarily the same as the response Apigee will see when it invokes the backend. There may be other network devices or systems in the data path when Apigee is in place, and those systems could be injecting headers into the response.  So please check, probably via a debug session in Apigee, the headers that Apigee is receiving when the error occurs.  If you can capture a trace session and don't mind sharing it, you could post it here, and I can have a look at it. 

 

Dear @dchiesa1 ,

I am waiting for the backed team to update the response headers, Once they have done it, I will check it and replay it here.

Thank you

 

Dear @dchiesa1 

I have received the backend team's response,

We checked and have the below observation :

1- Removing Transfer-Encoding: chunked without good reason might reduce the performance of dynamic responses,

2- Especially for large payloads. We need to ensure that the application use case justifies this change.

3- Removing is not the clean solution.

What is your suggestion, please?

 

Dear @dchiesa1 

The backend team removed the header 

< Transfer-Encoding: chunked

And the proxy is working fine now.