Apigee responds with 504 error for backend response 304

sujnana
Participant IV

We are facing similar issue mentioned in this link - https://community.apigee.com/questions/70530/for-304-status-code-from-services-the-gateway-take.html

The Apigee sends 504 error to client, however the response received from target is 304 and we can see the http header Content-Encoding: gzip. As per above link Apigee tries to open gzip and waits for response.

Why Apigee is waiting & timing out with 504 when target service is responding with 304. I agree the target is sending header Content-Encoding: gzip for empty body but Apigee should ignore this header as target response code is 304. The http code should take priority. I believe this should be the expected behavior as per HTTP standards. Is this a bug on Apigee side.

Is there a way to resolve this issue without any change on target service?

0 8 623
8 REPLIES 8

How long does your backend take to get the response back to Apigee?

The issue here is not backend. Backend is responding with 304 (means not not modified & no body) almost immediately. It waits till 55 seconds (55 is the timeout configured) & sends response with 504.

Not applicable

If the response received from backend is 304 and Apigee is returning 504, then the router is closing the connection before the backend responds. You need to increase the router timeout more than the time taken by the backend. Also need to check in trace how much time it takes to give the status code in trace.

In the case of longer time, I would suggest to enable both request and response streaming both in proxy and target endpoint. And share what you see.

This is not a case for streaming. The http 304 means content not modified & there is no response body. The backend is responding with 304 & closing the connection. However, Apigee is trying to open gzip (due to Content-Encoding header) and waiting for the response content. As per http specification there is no response content for HTTP 304 as client (browser) already cached the content. I would say this is incorrect implementation or a bug on Apigee as it is waiting for response body based on Content-Encoding header. It should have returned response as soon as it received http 304 response from client.

Yes I got. Why I said streaming is, during streaming gzip doesn't happen.

I would suggest if the content is not modified then you can use response cache.

Implementing caching on apigee side for not recommended. HTTP 304 response indicates that there is no need to retransmit the requested resources. That means client has already cached the content and nothing changed on server side. Hence caching on apigee side is not applicable for this scenario.

Hello @Sujnana - You may try intercepting the incoming call from browser to Apigee and remove the header 'If-Modified-Since' using Assign Message before sending the request to Target. I am not sure if it would work but worth a try.

Not applicable

How is it? I think this very effective method/