Короче говоря, я хотел бы явно указать данный алгоритм хеширования (SHA256), который использовался для вычисления заголовка HTTP ETag ресурса.Насколько я понимаю, значение заголовка ETag является непрозрачным, но на практике его обычно вычисляют с использованием хэш-функции.
Я понимаю идею сохранения значения ETag непрозрачным, что, я думаю,чтобы предотвратить непреднамеренную оптимизацию путем кэширования прокси-серверов, которые будут пытаться интерпретировать его значение и делать что-то, кроме сравнения текущего ETag с кэшированным ETag.Однако мне было интересно, написал ли кто-нибудь RFC, определяющий использование дополнительного HTTP-заголовка, который бы явно указывал алгоритм хеширования, используемый для вычисления соответствующего значения ETag, что делает его непрозрачным, оставаясь совместимым с кеширующими прокси, которые полагаются только нанепрозрачное значение ETag.
В моем случае я не использую кеширующий прокси: у меня есть нативное приложение, которое должно извлекать несколько ресурсов из собственного микросервиса HTTP, что означает, что я контролирую как реализацию клиента HTTP, так и сервера.Некоторые из этих ресурсов предназначены для хранения на диске, и в качестве оптимизации я хотел бы просто загрузить текущий файл, вычислить его сумму SHA256 и использовать его в качестве ETag последнего кэшированного ресурса при повторном извлечении того же ресурса из моегоmicroservice.
Другими словами: я делаю GET-запросы к конкретному ресурсу, который не часто меняется, но мне все равно нужно проверять через регулярные промежутки времени.Вместо того, чтобы каждый раз передавать ресурс по сети, я хотел бы вычислить сумму файла SHA256 и использовать ее как ETag, что позволит мне избежать сохранения непрозрачного ETag рядом с файлом.Поскольку я контролирую микросервис, обслуживающий ресурс, я могу легко использовать суммы SHA256 в качестве ETag и добавить собственный заголовок, чтобы указать, что SHA256 использовался для вычисления ETAg.Этот ETag может оставаться непрозрачным для клиентов, которые не проверяют пользовательский заголовок, но те, которые могут, будут обрабатывать его как сумму SHA256.
Существуют ли известные реализации чего-то подобного?Я хорошо использую неясный RFC, который не получил широкого распространения, или некоторую документацию по REST API, но я бы предпочел поискать существующие проекты, которые я мог бы реализовать, прежде чем создавать свои собственные.Если бы я пропустил широко признанный стандарт, это было бы больше, чем я хотел бы:)