Почему ответы на запросы PUT НЕ ДОЛЖНЫ предоставлять ETag?

От Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content:Почему ответы на запросы PUT НЕ ДОЛЖНЫ предоставлять ETag?

Сервера происхождения НЕ ДОЛЖЕН отправить поле заголовка валидатора (Section 7.2), такие как ETag или Last-Modified поле, в успешном ответ на PUT, если данные по представительству просьбы никогда было спасен без какого-либо преобразование, применяемое к телу (то есть новые данные представления ресурса идентичны данным представления, полученным в запросе PUT), а значение поля валидатора отражает новое представление. Это требование позволяет агенту пользователя знать, когда тело представления, которое оно имеет в памяти, остается текущим в результате PUT, поэтому ему не требуется снова получать исходный сервер и новый валидатор (ы), полученный в ответ может использоваться для будущих условных запросов во избежание случайных перезаписей (Section 5.2).

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

PUT Обратите внимание, что это единственный глагол, имеющий раздел относительно валидатора заголовков (см GET/POST/DELETE/PATCH).

источник

2017-02-15 sp00m

Я не вижу здесь противоречия. Главное, что сервер может вернуть Etag только в том случае, если то, что было на самом деле, было отправлено клиентом. Если сервер изменил данные, клиент должен будет получить контент, используя последующий запрос GET. –

Ключевым моментом является то, что сервер может или не может изменять представление перед его сохранением. В разделе вы связаны с:

Успешная PUT данного представления будет предположить, что последующее GET на тот же целевой ресурс приведет к эквивалентному представлению отправляется в 200 (OK) ответ. Тем не менее, нет никакой гарантии, что такое изменение состояния будет наблюдаемым, поскольку цель ... может подвергаться динамической обработке сервером происхождения.

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

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

Если представление было изменено, то представление пользовательского агента по определению недействительно. Поэтому заголовок валидатора не возвращается, и пользовательскому агенту необходимо выполнить безусловный GET.

источник

2017-02-15 11:57:56

Спасибо, еще один вопрос: клиент имеет версию ресурса, модифицирует его, выдает его на сервер, который применяет дополнительные модификации и возвращает новое представление клиенту. В этом случае тело запроса! = Тело ответа. Почему сервер не может предоставить новый ETag непосредственно в ответ? Затем клиент мог проверить, соответствует ли его локальный ETag ответ в ответ и соответствующим образом обновить его кеш. Это позволит избежать повторного получения ресурса (в котором ответ будет иметь тот же самый орган, что и ответ PUT, но на этот раз с ETag) ... – sp00m

@ sp00m: Я думаю, что путаница здесь в том, что вы предполагаете, что сервер отправляет представление обратно в тело ответа на 'PUT'. Но это не так. Если вы управляете сервером, вы можете это сделать, конечно, но это не входит в стандарт. Таким образом, в общем, нет никакого способа, чтобы пользовательский агент мог узнать новое представление без выполнения нового (безусловного) 'GET'. –

О, да, вот именно то, чего мне не хватало :) Спасибо! – sp00m

Почему ответы на запросы PUT НЕ ДОЛЖНЫ предоставлять ETag?

ответ

Смежные вопросы