Должен ли я включить тип медиа в моем ETag? - PullRequest
6 голосов
/ 02 ноября 2011

При добавлении ETag к HTTP-ответу следует ли указывать тип носителя? Конечно, я понимаю, что ETag непрозрачен, но вот пример:

  • Скажем, у меня есть клиент, который запрашивает пользователя в приложении / json. Я смотрю его, создаю свой ETag и отправляю обратно JSON-представление человека
  • Теперь тот же клиент делает другой запрос для того же человека (который не был изменен) по тому же URI, но хочет его в application / xml.

Ясно, что некорректно просто возвращать 304, но мой вопрос, во втором запросе, можно ли ожидать совпадения ETag, но без кеша на основе заголовка Accept (или заголовка содержимого). Кроме того, возможно ли, что кэш будет иметь два представления из одного и того же URI, или у вас всегда будет неверный кэш каждый раз, когда ваш Content-Type переключается?

Ответы [ 2 ]

5 голосов
/ 02 ноября 2011

Разным представлениям нужны разные теги сущностей.

См. http://trac.tools.ietf.org/wg/httpbis/trac/ticket/39.

0 голосов
/ 24 июля 2012

Я считаю, что вы можете отправить один и тот же Etag для разных представлений. Пока вы указываете, что они должны быть кэшированы как два разных объекта, в вашем ответе. Это можно сделать с помощью поля Vary, как описано в RFC 2616

http://www.ietf.org/rfc/rfc2616.txt

14,44 Варь

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

Использование Vary: Accept должно быть уместным.

...