Я использую URLSession со стандартной политикой кэширования useProtocolCachePolicy. Используя прокси-сервер, такой как Charles I, я могу убедиться, что кэширование работает, как и ожидалось, для запроса с Etag, где сервер возвращает HTTP-ответ 304 (не изменен). Однако кэширование URLSession скрывает этот код ответа и вместо этого выполняет мои обработчики завершения запросов с кодом состояния 200 с кэшированными данными. Я понимаю, что это так, как ожидается, поскольку библиотеки Foundation инкапсулируют это поведение. Однако у меня есть сценарий, который требует изменения пользовательского интерфейса на код ответа 304.
Есть ли какой-нибудь делегат или обработчик, который я могу использовать, чтобы заглянуть в реальный код состояния до того, как библиотеки Foundation сделают свое волшебство?
Один из возможных обходных путей - подсказка @ChanchalChauhan, заставляющая URLRequest игнорировать локальный кеш (путем установки политики кеширования .reloadIgnoringLocalCacheData) и добавление HTTP-заголовка If-None-Match вручную со значением, извлеченным из CachedURLResponse, полученного из URLCache для запроса. Однако для завершения этого решения эта логика должна выполняться только в том случае, если срок действия кэшированного ответа истек, так как в противном случае сетевой запрос не требуется. Я не нашел способ определить, истек ли срок хранения в кэше.