I have a simple request with 2 headers and GET call with path parameter. It’s failing even before sending a request to the backend server.
{ “fault”: { “faultstring”: “chunked MUST be the last transfer-coding applied to the message-body”, “detail”: { “errorcode”: “protocol.http.ChunkedShouldBeLast” } } }
Anyone knows about this error?
Apigee Edge is complaining that there is a Transfer-Encoding header that includes “chunked” but that coding is not the LAST transfer-coding in the header.
IETF RFC 2616, the original document that defined HTTP, says:
Whenever a transfer-coding is applied to a message-body, the set of transfer-codings MUST include “chunked”, unless the message is terminated by closing the connection. When the “chunked” transfer- coding is used, it MUST be the last transfer-coding applied to the message-body. The “chunked” transfer-coding MUST NOT be applied more than once to a message-body. These rules allow the recipient to determine the transfer-length of the message.
Have you checked that the inbound message has a valid Transfer-Encoding header?
Thanks, @Dino for your response.
I don’t have any Transfer-Encoding in the header. Request header contents token and ClientHeader, which are generic in nature. Also, the weird part is if I truncate the path parameter, it is able to hit the backend server. I tried a couple of combinations, truncating the path or removing headers it’s able to hit the backend server. However, with all the parameters, it gives an error.
Any thoughts?
If I were debugging this, I’d want to understand what message was being received by the API Proxy. You say you don’t have a Transfer-Encoding header - but maybe there is some intermediary party placing that header into the request?
I looked into the logic; I don’t see a way to get this error without the presence of a Transfer-Encoding header in the request.
I think you’re pursuing in the right way - just break it down, try a bunch of combinations, and see what causes the problem. That ought to help you isolate it and diagnose it.
I’m using postman and sending a request. PFA for client request trace.
If I apply all 3 in the request. DateRange(with special chars) in URL, Token, and clientHeader, I am getting a 502 bad gateway. However, if I change any of the 3 in the request, it is able to hit the target server.
Prabin, is this an OPDK installation?
Similar report here.
Thanks Dino, its a duplicate report. I’ll remove mine and work through this one.
Yes, its an OPDK installation, 4.17.05
Is this still an issue? can you download the trace and send? @Josh Stone
@Maruti Chand Yes, it is still an issue. I found out that it is hitting the backend target server and the response from target server is returning data with transfer-encoding=[chunked]. However, apigee is not sending the response back to the client. Also, I have added assign message step on the response to remove the transfer-encoding from target server. Still no luck.
