304 status code goes to fault flow

[sujnana]

As per document by default, Apigee Edge treats HTTP code 4XX or 5XX as errors, and it treats HTTP code 1XX, 2XX, 3XX as succes. We can change this using success.codes property under Target endpoint. However, we are seeing the proxy treating 304 as error in our proxy. There is no properties defined in HTTPTargetConnection on our proxy.

HTTPTargetConnection configuration:

<HTTPTargetConnection>
        <LoadBalancer>
            <Server name="AdS12Target"/>
        </LoadBalancer>
        <Path>/</Path>
    </HTTPTargetConnection>

Trace:

The red highlighted policies are under DefaultFaultRule. I also see the gateway taking long time even though the backend responding fast.

I can see the similar issue reported here - https://community.apigee.com/questions/70530/for-304-status-code-from-services-the-gateway-take.html

Is this a bug?

@Dino-at-Google

[dchiesa1]

Do you have a success.codes property defined on the TargetEndpoint?

https://docs.apigee.com/api-platform/reference/endpoint-properties-reference#targetendpointtransport...

If you do, it needs to include 3xx or 304.

On the other hand, I see the Apigee proxy returning a 504.... Which is a Gateway Timeout. And the response time for that request is over 55 seconds. I'm not sure what is going on, but it sure seems like a timeout somewhere in the system. I don't know where the 304 comes from.

The image of your Trace UI is not sufficient for me to understand what's going on. If you could attach a trace session, I would be able to give you more insight.

[sujnana]

There is no success.codes property is defined on the TargetEndpoint.

The 304 response is from target. We can see the target service is responding 304 in a few milliseconds. We can see the 304 response on TargetEndpoint. I am not sure where the status code changed to 504. I can't attach trace file due to security reasons. However, we have created support ticket and provided the trace file & other information. Case No: 1476424.

[ahorner]

We were running into this same issue with HTTP 204 and 304 responses from origin. The fix is to remove the Content-Encoding response header at origin when these status codes are sent. I'm assuming that Apigee opens a gzip reader when Content-Encoding is set but there are no response bytes in the body so the gzip reader times out after 30 seconds (in our case). Good luck!

[#5]

You can follow this to list the response code into success.

https://community.apigee.com/questions/5200/does-setting-successcodes-on-targetendpoint-overwr.html