- From: John Sullivan <jsullivan@velocix.com>
- Date: Tue, 26 Jun 2012 16:22:59 +0100
- To: Mark Nottingham <mnot@mnot.net>
- CC: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Mark Nottingham wrote: > Now <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/363>. > > > On 23/06/2012, at 9:28 PM, Julian Reschke wrote: > >>> "HTTP/1.0 clients and caches might ignore entity-tags. Generally, last-modified values received or used by these systems will support transparent and efficient caching, and so HTTP/1.1 origin servers SHOULD provide Last-Modified values. In those rare cases where the use of a Last-Modified value as a validator by an HTTP/1.0 system could result in a serious problem, then HTTP/1.1 origin servers SHOULD NOT provide one." >>> >>> DESIGN - What are the "rare cases" being talked about here, and how are servers supposed to detect them? >> >> Good question. We may want to drop this. 1) Algorithmically generated output where ETag can represent the current control or seed values directly, but generating Last-Modified would require extra persistent storage. 1b) Resources gatewayed from systems that have no concept of last-modification time, but ETag along with the URL can again represent parameters that are guaranteed to retrieve the same entity or detect a change/error. 2) Rapidly changing, but cacheable, resources, where the origin knows that Last-Modified could never become strong by S13.3.3. Normally harmless but pointless. If it suspects that a downstream would wrongly use the weak Last-Modified where it shouldn't, then it might want to avoid that dangerous possibility altogether. John --
Received on Tuesday, 26 June 2012 15:23:36 UTC