Azure Проблема с кэшем управления API

Question

Цель: использование политики кэширования управления API для кэширования ответа json, который никогда не изменяется.

Оригинал (без кэша)
Эта политика поддерживается функцией azure, которая никогда не возвращает -изменяющий json ответ.

<policies>
    <inbound>
        <base />
        <set-backend-service id="apim-generated-policy" backend-id="azfunc-fluffyoauth2" />
        <rewrite-uri template="/WellKnownOpenidConfiguration" />
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

Думая, что это может быть полезно для кеширования, я ввожу политику поиска в кеше.

<policies>
    <inbound>
        <base />
        <set-backend-service id="apim-generated-policy" backend-id="azfunc-fluffyoauth2" />
        <rewrite-uri template="/WellKnownOpenidConfiguration" />
        <cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none" />
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
        <cache-store duration="36000" />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

Что я вижу, так это то, что кэшированная версия возвращает двоичный файл, который, по моему мнению, является gzipped. Это приводит к тому, что нижестоящий код ожидает, что он будет неформатирован json. Этот ответ является документом открытия openid connect, и по иронии судьбы, если я укажу на это jwt-policy API Management, он также нарушается.

то есть

var auth0Domain = "https://apim-mycompany.azure-api.net/oauth2";
string responseString = null;
try
{
    var url = $"{auth0Domain}/.well-known/openid-configuration-cached";
    Console.WriteLine($"-------------------");
    Console.WriteLine($"{url}");
    var httpClient = new HttpClient();
    var response = await httpClient.GetAsync(new Uri($"{auth0Domain}/.well-known/openid-configuration-cached"));
    responseString = await response.Content.ReadAsStringAsync();
    Console.WriteLine($"-------------------");
    Console.WriteLine($"{responseString}");
    Console.WriteLine($"-------------------");
    JsonConvert.DeserializeObject<OpenIdConnectConfiguration>(responseString);
}
catch (Exception ex)
{
    Console.WriteLine($"Error:{ex.Message}");
    Console.WriteLine($"-------------------");
    return;
}



curl -I --location --request GET 'https://apim-fluffyoauth2.azure-api.net/oauth2/.well-known/openid-configuration-cached'
HTTP/1.1 200 OK
Cache-Control: no-store, must-revalidate, no-cache
Pragma: no-cache
Content-Length: 558
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
Expires: Tue, 14 Apr 2020 18:50:53 GMT
Vary: Accept-Encoding
Request-Context: appId=cid-v1:dfeba42c-e636-42bc-b501-7c77563c3e7b,appId=cid-v1:dfeba42c-e636-42bc-b501-7c77563c3e7b
Date: Tue, 14 Apr 2020 18:50:53 GMT

Вопрос (ы):

Что делает политика кэширования?
Как я могу изменить ее на статичный кеш, но ответить каким НЕКЕШЕННАЯ версия делает?

Answer 1

Добавление следующего:

<cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none">
  <vary-by-header>Accept</vary-by-header>
  <vary-by-header>Accept-Charset</vary-by-header>
</cache-lookup>

, который создает окончательную политику.

<policies>
<inbound>
    <base />
    <set-backend-service id="apim-generated-policy" backend-id="azfunc-fluffyoauth2" />
    <rewrite-uri template="/WellKnownOpenidConfiguration" />
    <cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none">
        <vary-by-header>Accept</vary-by-header>
        <vary-by-header>Accept-Charset</vary-by-header>
    </cache-lookup>
</inbound>
<backend>
    <base />
</backend>
<outbound>
    <base />
    <cache-store duration="3600" />
</outbound>
<on-error>
    <base />
</on-error>

Теперь управление API не выполняет кодировку gzip, когда об этом не просили.

Мне все еще интересно, почему API Management внезапно перестанет выполнять gzip-кодирование для исходной проблемы. Иногда это делалось, затем останавливалось, что приводило к некоторой путанице относительно того, что происходило.