Заголовки If-None-Match игнорируют Content-Type и Vary

Question

У меня есть веб-приложение, которое обслуживает как HTML, так и несколько форматов RDF (в приведенном ниже примере это RDF / XML). Страница загружается как HTML (естественно), а затем запрашивает собственный URL-адрес как RDF / XML.

Проблема: она выглядит как Firefox 74.0 (64-разрядная версия) (при Windows) ) смешивает ETag значения из этих двух запросов, игнорируя различные Content-Type с, а также присутствующие Vary: Accept.

Когда я перезагружаю страницу, я вижу, что она использует ETag: "95e11fbc9e816b56" из второй (RDF / XML) ответ в запросе на HTML, и наоборот:

Request URL: https://localhost:4443/6a6283d2-2a40-4882-b89d-8073a7c30e17/

Host: localhost:4443
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://localhost:4443/6a6283d2-2a40-4882-b89d-8073a7c30e17/
Connection: keep-alive
Cookie: _ga=GA1.1.828629977.1584086266; LinkedDataHub.first-time-message=true
Upgrade-Insecure-Requests: 1
If-None-Match: "95e11fbc9e816b56"
Cache-Control: max-age=0

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=31536000;includeSubDomains
ETag: "95e11fbc139f56de"
Cache-Control: max-age=3600, public
Last-Modified: Wed, 12 Feb 2020 23:05:15 GMT
Vary: Accept-Charset,Accept,Accept-Encoding
Content-Type: text/html;charset=UTF-8
Transfer-Encoding: chunked
Content-Encoding: gzip
Date: Sun, 22 Mar 2020 10:13:43 GMT

Request URL: https://localhost:4443/6a6283d2-2a40-4882-b89d-8073a7c30e17/

Host: localhost:4443
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0
Accept: application/rdf+xml
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://localhost:4443/d376ee88-ff7d-48ee-81c4-1220c9f482f0/
Connection: keep-alive
Cookie: _ga=GA1.1.828629977.1584086266; LinkedDataHub.first-time-message=true
If-None-Match: "95e11fbc139f56de"
Cache-Control: max-age=0

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=31536000;includeSubDomains
ETag: "95e11fbc9e816b56"
Last-Modified: Wed, 12 Feb 2020 23:05:15 GMT
Vary: Accept-Charset,Accept
Content-Type: application/rdf+xml;charset=UTF-8
Transfer-Encoding: chunked
Date: Sun, 22 Mar 2020 10:13:55 GMT

На Chrome я не могу заставить его отправлять If-None-Match заголовки в все, но это, вероятно, из-за самозаверяющего сертификата .

Обратите внимание, что значения ETag похожи, но различны: "95e11fbc139f56de" против "95e11fbc9e816b56".

Это не имеет никакого смысла для меня. Есть объяснения? Спасибо.

Соответствующей спецификацией является Протокол передачи гипертекста (HTTP / 1.1): условные запросы .

Answer 1

Проблема, по сути, заключается в том, что вы полагаетесь на поведение, которое не предписано стандартом HTTP и не реализовано браузерами.

Чтобы ваша схема работала, браузеры пришлось бы хранить несколько представлений одного ресурса в своем кэше. К сожалению, как обсуждалось в статьях , таких как эти , они этого не делают.

Браузеры, как правило, не реализуют возможность хранить несколько вариантов на URL , Основанием для этого является то, что вещи, для которых мы обычно используем Vary (в основном Accept-Encoding и Accept-Language), не часто меняются в контексте одного пользователя.

Так что проблема не в ETags означает, что браузер просто перезаписывает одно представление в своем кеше каждый раз, когда получает другое представление.

Если браузер сохранял несколько представлений, схема должна работать нормально. В этом случае обратите внимание, что именно сервер, а не клиент выбирает несколько ETags. Клиент отправит заголовок If-None-Match со всеми ETags, о которых он знает, и сервер должен будет решить, какой из них, если таковой имеется, соответствует запрошенному представлению.

Согласно статье выше, пограничные серверы (в отличие от браузеров) сохраняют несколько представлений в кэше для каждого ресурса, поэтому все же возможно, что ваша схема может привести к повышению производительности.