0
votes

In my Azure API Managemenent I'm defining a header based caching policy at API level. The policy is quite simple:

<policies>
        <inbound>          
          <check-header name="token" failed-check-httpcode="400" failed-check-error-message="Token header is missing" ignore-case="true" />
          <cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none">
            <vary-by-header>token</vary-by-header>
          </cache-lookup>
          <base />
        </inbound>
        <backend>
          <forward-request />
        </backend>
        <outbound>
          <cache-store duration="3600" />
          <base />
        </outbound>
        <on-error>
          <base />
        </on-error>
    </policies>

This works ok in the case my downstream returns a 200 with a body - next request with same header token will hit the cache and the response will be returned from the API Management cache.

However is a error code is returned by the downstream (eg: 401 Unauthorized) that response is not cached by the API Management (confirmed by the tracing I've enabled on the API Management). I was under the impression that whole responses are cached, but this doesn't seem to be the case...

Can somebody let me know if it's possible to cache responses also in case of unsuccessful http codes and if yes point me to some doc - I've been googling all day yesterday, but was unable to find more.

Thanks in advance!

1

1 Answers

0
votes

This is by design. If you look into traces you should see message there "Backend service responed with the status code of 401 rather than 200 OK. Cache Store policy was not applied." The reasoning is that at APIM level we assume that non 200 responses are more transient than 200.

Say that client gets 401, goes on to do whatever to make sure that token is allowed to do the operation and retries the call. And still gets 401 from cache until cache expires.

That certainly may be added as an extra configuration option on a policy: http://aka.ms/apimwish

You could workaround that by using cache-lookup-value and cache-store-value. I.e. in the outbound section if you get 401 store some value in cache using cache-store-value to keyed with token. And in the inbound before cache-lookup do cache-lookup-value with token and see if you get value stored earlier. If you do you can generate 401 response right in place.