chunked MUST be the last transfer-coding applied to the message-body

[#1]

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?

trace-errro.jpg

[DChiesa]

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?

[#3]

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?

[DChiesa]

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.

[#5]

trace-client-request.jpg

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.

[DChiesa]

Prabin, is this an OPDK installation?

[#7]

Yes, its an OPDK installation, 4.17.05

[#8]

Is this still an issue? can you download the trace and send? @Josh Stone

[#9]

@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.

[#10]

@Maruti Chand

@Prabin Shrestha

See attached trace.

trace.txt

[DChiesa]

Similar report here.

[#12]

Thanks Dino, its a duplicate report. I'll remove mine and work through this one.