Response cache policy does not cache error responses (403 for example)

[#1]

Hi,

I have a response cache policy where I want to cache a response (both successes and errors), based on a key in the request.

The policy caches the 200's fine, but 403's or any other reponses i.e non 2xx or 3xx are not cached. The cache.hit value for these remain 0

My responsecache policy looks like this:

<ResponseCache name="my-response-cache">

<CacheKey> <KeyFragment ref="some_var" /> </CacheKey>

<ExpirySettings> <TimeoutInSec>600</TimeoutInSec> </ExpirySettings>

<ExcludeErrorResponse>false</ExcludeErrorResponse>

</ResponseCache>

Please advise.

Thanks in advance

[adas]

@Trupti Your response cache policy seems fine. You have set the ExcludeErrorResponse to false which means all responses irrespective of 2xx or 3xx would be cached. I would like to see if you have any conditions in the ResponseCache step. If not, then this should work. If you want you can share your api-proxy so that I can take a look. Must be something really minor otherwise the functionality does work fine. I just confirmed the same with a simple apiproxy that I wrote.

[#3]

Hi Arghya,

Thanks for your reply.

Please find my api-proxy attached.

Cheers

Trupti

[#4]

Hello,

Can anyone else help please?

Could it be a version related problem? We are using - (Premises) Edge 4.15.04.00

Thanks in advance

Trupti

[sarthak · Accepted solution]

Hi @Trupti , I did some further testing and this is what I found out :

ExcludeErrorResponse controls 2XX and 3XX codes as by default Apigee only considers 200 to 205 codes to be successful. ExcludeErrorResponse do not have any effect on 4XX and 5XX status codes

Add the following in your target/default.xml and all the error codes which you want Apigee to consider as success.

<Properties>    

    <Property name="success.codes">404</Property>         

</Properties>

Read more here : http://apigee.com/docs/api-services/reference/endpoint-properties-reference

This works fine for me. Now I can cache 404 error codes as well.

Let me know if this helps.

[adas]

@Trupti I went back and looked at the code and also confirmed with my folks in engineering about this. Turns out, whatever @sarthak was proposing is the way to make it work. For 4xx and 5xx errors the flow would not be executed which means it you never hit the cache policy in the response flow, so that these responses would never be cached. By setting the success codes for the target endpoint, you are actually forcing the flow to continue and the cache policy to execute.

This appears to be a documentation bug. I will work with the doc team to get that fixed to avoid any confusion. Hope this helps. And sorry for the confusion earlier.

[#7]

Thanks for the update @arghya

[adas]

@Trupti This looks to be a regression bug. I am pretty sure this used to work a while back. I actually tried out the same thing on our current cloud version, and even there it was not caching the 4xx and 5xx responses, even with the ExcludeErrorResponse set to false. I have logged a bug with the engineering team. Will post more updates once I have some visibility into the fix.

[adas]

@sarthak What you are proposing would work, but then its more of a work around. You are overriding the success codes definition by setting 4xx as a success code for example. This might affect analytics and other stuff too, since Edge would now treat 4xx as a success code for that endpoint. The response cache policy is supposed to work irrespective of that, if you set ExcludeErrorResponse to false. Here's a line from the documentation about response cache policy

Currently, by default, this policy caches HTTP responses with any possible Status code. That means both success and error responses are cached.

So I still think its a bug and most probably it was recently introduced because this worked fine earlier.

[sarthak]

Yaah I agree . I have not played with this property before and hence was not sure if this was the intended funcationality or not. I want to test how setting the value impacts 3XX response codes.

[#11]

Thanks for replying guys. Please keep me posted about the bug and it's fix @arghya. Thanks for the work around @sarthak but I suppose we will need to wait for the fix.

Cheers

Trupti

[shalinisingh]

Hello @arghya das is this issue reported by @Trupti resoved? I can still see this same issue. and I am not able to cache the error response.

,

@Arghya Das , didn't this still resolve? I am facing the same issue as of @Trupti