- From: Brian Smith <brian@briansmith.org>
- Date: Tue, 29 Jul 2008 13:41:41 -0500
- To: "'Julian Reschke'" <julian.reschke@gmx.de>, "'Mark Nottingham'" <mnot@mnot.net>
- Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Julian Reschke wrote: > Julian Reschke wrote: > > ... > > Mark and I discussed this yesterday, and Mark came up with > a concrete > > proposal (see > <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/101>): > > ... > > Proposed patch: > <http://www3.tools.ietf.org/wg/httpbis/trac/attachment/ticket/ > 101/i101.diff>. > > Note this also drops a leading "In order to be legal..." > intro -- it's not like we ever talk about entity tags > behaving illegally :-) "entity value" is an undefined term that is only used in this one place, and it could be interpreted as "entity body" inappropriately. "Entity" would be better since it is defined as the combination as the entity-header fields and the entity-body. I would expect that a validator should change whenever the entity changes, *and* whenever the entity *headers* change as well. For example, changing the Content-Type from text/plain to text/html is a significant change even if the entity body stays the same. Otherwise, because of the restrictions on 304 responses containing entity headers, the client could repeatedly get 304 responses and never learn that the content-type changed. Similarly, conditional PUTs would unknowingly revert an intermediate change in entity headers. For example, an ETag generated as the MD5 of just the entity body would not be a good ETag, but an ETag generated as the MD5 of the entity headers together with the entity body would be a good ETag. - Brian
Received on Tuesday, 29 July 2008 18:42:17 UTC