Getting 204 Response with message body

[abiramradhakris]

Hi,

When I use pass-Thro proxy to invoke the Target (backend), response in Apigee looks like below

502 Bad Gateway

{"fault":{"faultstring":"Received 204 Response with message body","detail":{"errorcode":"protocol.http.ResponseWithBody"}}}

But when I invoke the backend bypassing the apigee I get the 204 without body.

Per HTTP specification if the 204 should not have the Body content when debug the trace looks like Apigee adding the body for 204 response as well (which is not expected by client) .Did any one face same problem ?

[amitkumar2091]

Mentioned fault is generated by apigee not by client because target response have a body with status code 204. apigee is not adding anything in body.

Most of the rest clients omits body when status code is 204 No Content , so its tricky to verify whether target is sending a body or not with clients like postman.

Can you please curl target and check or provide the response along with headers ? Also please provide apigee trace if possible.

[abiramradhakris]

CURL to target is few i just modified few but its similar..

curl -X GET -H 'Accept: */*' -H 'accept-encoding: gzip,deflate' -H 'Authorization: *********' -H 'cache-control: no-cache' -H 'Content-Type: application/xml' -H 'cookie: BlueStripe.PVN=5ad400011gd0' -H 'Postman-Token: d6b10440424d' -H 'X-Forwarded-For: XX.YY.MMM.ZZ' -H 'X-Forwarded-Port: 443' -H 'X-Forwarded-Proto: https' 'https://backend.target.com/v1/hello/world'

Body

{

"fault": {

"faultstring": "Received 204 Response with message body",

"detail": {

"errorcode": "protocol.http.ResponseWithBody"

}

}

}

Let me know your view

[amitkumar2091]

What i meant was to curl back end directly without involving apigee , based on your response body i am guessing you are still hitting apigee. Please use -i with your curl as we can check presence and value of content-type header in back end response. Most probably curl will also not going to display response body with status code 204.(https://tools.ietf.org/html/rfc7231#section-6.3.5 )

I am pretty sure there is some issue in back end response as i have created multiple reverse proxy with 204 status and never faced this issue.

[abiramradhakris]

@Amit Kumar when ran the CURL with -k -v -i option got following

I have listed CURL invocation to back end (which Apigee creates for directly invoking backend .this is same CURL we see during DEBUG trace )

looks like Apigee converts such situation to a fault ...).This is Passthro proxy in apigee without any fault handling.

When backend sends HTTP 204 with no content (which is success) but I think Apigee treats this as fault. Please let me know if you have different understanding..

> GET /v1/hello/wrld HTTP/1.1

> Host: host.dnsname.com

> User-Agent: curl/7.55.0

> Accept: */*

> accept-encoding: gzip,deflate

> Authorization: Basic nnnnnnxxxxx==

> cache-control: no-cache

> cookie: BlueStripe.PVN=3bd400001bc0

> Postman-Token: 78885-995-12a-a8-35f51f107

> X-Forwarded-For: yy.1n.1y6.x0

> X-Forwarded-Port: 443

> X-Forwarded-Proto: https

>

{ [5 bytes data]

< HTTP/1.1 204 No Content

< Cache-Control: no-cache

< Pragma: no-cache

< Content-Length: 18

< Content-Type: application/json; charset=utf-8

< Expires: -1

< Server: Microsoft-IIS/8.5

< X-TPS-TransactionGUID: e7bd9190-2b7-48-b01d-6134e0238

< X-AspNet-Version: 4.0.30319

< X-Powered-By: ASP.NET

< Date: Fri, 27 Apr 2018 19:51:51 GMT

<

* Excess found in a non pipelined read: excess = 18 url = /v1/hello/wrld (zero-length body)

0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0HTTP/1.1 204 No Content

Cache-Control: no-cache

Pragma: no-cache

Content-Length: 18

Content-Type: application/json; charset=utf-8

Expires: -1

Server: Microsoft-IIS/8.5

X-TPS-TransactionGUID: bd0-27-48-b0-6d95134e0

X-AspNet-Version: 4.0.30319

X-Powered-By: ASP.NET

Date: Fri, 27 Apr 2018 19:51:51 GMT

[abiramradhakris]

@Amit Kumar to add to above, with POSTMAN direct invoke to backend (without Apigee)

Responds with below information

Request https://DNSName//v1/hello/wrld Passing required credentials in POSTMAN.

No information available to return.

Response (no content) (header: Status: 204 No Content)

Note: Here there is no content for 204 HTTP response when invoked without APigee directly to backend with POSTMAN

[umannggoel]

@Abiram Radhakrishnan

Please remove the "Header" accept-encoding: gzip,deflate from the request part which is going to backend, You will able to get success 204 response from Backend without any error at Apigee end.

[abiramradhakris]

@Umanng @Umanng

I removed -H 'accept-encoding: gzip,deflate' in the CURL and invoked the API of Apigee so that it can hit backend service but I am still getting Error response 204 (wh

curl -X GET -H 'Accept: */*' -H 'Authorization: Basic XXjj' -H 'cache-control: no-cache' -H 'cookie: BlueStripe.PVN=RRCCX' -H 'Postman-Token: 7a-4a-5y-6x' -H 'X-Forwarded-For: 5x.2d.2xx.4y' -H 'X-Forwarded-Port: 443' -H 'X-Forwarded-Proto: https' 'https://orgname-development-apigee.net/APIName/helo/world/ddd?param=name -k -v –i

I have also fired the same request bypassing the Apigee url and directly invoking thre backend as below

curl -X GET -H 'Accept: */*' -H 'Authorization: Basic XXjj' -H 'cache-control: no-cache' -H 'cookie: BlueStripe.PVN=RRCCX' -H 'Postman-Token: 7a-4a-5y-6x' -H 'X-Forwarded-For: 5x.2d.2xx.4y' -H 'X-Forwarded-Port: 443' -H 'X-Forwarded-Proto: https' 'https://backendURL.com/helo/world/ddd?param=name -k -v –i

Even i tried adding below for TargetEndpoint

<SSLInfo> <Enabled>true</Enabled> </SSLInfo>

I get 204 as Fault

Received 204 Response with message body

com.apigee.errors.http.server.BadGateway

Finally 502 Bad Gateway

{"fault":{"faultstring":"Received 204 Response with message body","detail":{"errorcode":"protocol.http.ResponseWithBody"}}}

Is sent to Client.

[umannggoel]

@Abiram Radhakrishnan
Since 204 Response code means no content only status code,But seems like the backend is passing some context with status code.
I also had a similar issue,While checking I found out that I need to remove the Accpet-Encoding header using Assign message at Target endpoint side.

And it worked for me as charm.

<Remove><Headers> <Header name="Accept-Encoding"/> </Headers> </Remove>

[abiramradhakris]

@Umanng

As you indicated, I removed the header from request in AssignMessage (in TargetEndpoint Preflow) before hitting backend

Assign message looks like below

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" name="AM-1">
<DisplayName>Assign Message-1</DisplayName>
<Properties/>
<Remove>
<Headers>
<Header name="Accept-Encoding"/>
</Headers>
</Remove>
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
<AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

hence CURL is displayed as below (once I debug)

curl -X GET -H 'Accept: */*' -H 'Authorization: *****' -H 'cache-control: no-cache' -H 'cookie: BlueStripe.PVN=3cccnnoo' -H 'Postman-Token: aaa-bb-8gggg2a29' -H 'X-Forwarded-For: AA.BB.CC6.D0' -H 'X-Forwarded-Port: xxx' -H 'X-Forwarded-Proto: https' 'https://hello.world.com/required/params/para

Debug still shows following which results in 502 bad Gateway even after removing the header information As below

Received 204 Response with message body

error.class com.apigee.errors.http.server.BadGateway

Expression ((error.state equals PROXY_REQ_FLOW) or (error.state equals PROXY_RESP_FLOW))

ExpressionResult false

Tree PROXY_FAULT_HANDLING

xpression ((error.state equals PROXY_REQ_FLOW) or (error.state equals PROXY_RESP_FLOW))(((error.state equals TARGET_REQ_FLOW) or (error.state equals TARGET_RESP_FLOW)) or ((error.state equals REQ_SENT) or (error.state equals RESP_START)))

ExpressionResult falsetrue

Tree PROXY_FAULT_HANDLINGTARGET_FAULT_HANDLING

Variables

error.state REQ_SENT

target.name default

Properties

Expression (((error.state equals TARGET_REQ_FLOW) or (error.state equals TARGET_RESP_FLOW)) or ((error.state equals REQ_SENT) or (error.state equals RESP_START)))("default" equals target.name)

ExpressionResult truetrue

Tree TARGET_FAULT_HANDLINGTARGET_default

Error Headers

Content-Type application/json

Error Content

Body

{"fault":{"faultstring":"Received 204 Response with message body","detail":{"errorcode":"protocol.http.ResponseWithBody"}}}

[vamshi2544]

I am facing similar issue, do we have a solution for this on how to handle 204 response from backend to apigee. Since it is handled as 502 by default fault. Any help is appreciated.

[tejassomaiya-1]

Hi Abiram Radhakrishnan - I'm facing the same issue? Appreciate, if you could assist in resolving this issue, if in case you have solution.

[tejassomaiya-1]

Hi @vamshi v - I'm facing similar issue? do we have solution to handle 204 response from backend to apigee?

[#14]

@Tejas, can you try hitting the backend directly and see the response. And try same request creating in Apigee.

[tejassomaiya-1]

Hi Priyadarshi Ajitav Jena - Many Thanks for the swift response.

Yes, I have checked the backend directly and it's returning the below result with status code 204, but at APIGEE layer it's showing 502 bad gateway.

{ "Response": { "title": "Not Found", "detail": "DATA_NOT_FOUND", "status": "204", "instance": "data" } }

Moreover, as mentioned in above thread I have placed below remove header as well but no luck.

<Remove><Headers> <Header name="Accept-Encoding"/> </Headers> </Remove>

Kind Regards,

Tejas

[#16]

I would suggest to enable streaming and see what it gives.