Почему разные Etags для разных представлений одного и того же ресурса? - PullRequest
Новая
       8

Почему разные Etags для разных представлений одного и того же ресурса?

14 голосов
/ 22 апреля 2011

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

В конце концов, разве нам не интересно знать, изменился ли ресурс , чтобы мы могли обрабатывать параллельные модификации? Мне трудно даже представить себе, когда представление ресурса изменится без изменения самого ресурса, поэтому мне явно не хватает некоторого базового понимания.

Ответы [ 2 ]

9 голосов
/ 22 апреля 2011

Хороший вопрос, и я думаю, что это вопрос некоторых дискуссий.

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

Проверьте следующие ссылки:

4 голосов
/ 10 января 2013

Это не является предметом споров, когда вы выкладываете факты или читаете спецификацию HTTP и HTTPbis.

ETag - это средство кэширования и контроля параллелизма.Слабые ETag - только средство кэширования бедняков.

С точки зрения кэширования (GET) - uri + content-type + etag может помочь вам сэкономить пропускную способность, не отвечая также на полезную нагрузку, но только с помощьюКод состояния 304.

С точки зрения управления параллелизмом (POST; PUT; PATCH) - стремительно рассчитывать ETag на основе URI + тип контента + полезная нагрузка ответа с точным битом.Почему?

  • Если вы вычисляете ETag на основе целого объекта, расширенного набора полезной нагрузки ответа (т. Е. Ваша полезная нагрузка дает a + b, но объект на самом деле a + b + c),затем выполнение PATCH, например, приведет к сбою, потому что ETag изменился ... вы обновляете ... вы получаете те же данные, но другой ETag ... вы повторяете PATCH с новым ETag, теперь он работает. FAIL
  • Если вы вычисляете ETag на основе подмножества полезной нагрузки, вы фактически лишаете пользователя возможности контролировать условия небезопасного вызова без какой-либо прозрачности вообще.PATCH будет успешным, даже если изменились данные, связанные с этим ETag, что явно не соответствует тому, как был задан HTTP-запрос. FAIL

Условные запросы должны обрабатываться с помощью семантики, аналогичной "Учитывая, что мой взгляд на мир все тот же, затем выполните запрос. В противном случае выполните ошибку".Мой взгляд на мир сделан из прошлого ответа (URI + заголовки + полезная нагрузка).

...