W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: WGLC #363: rare cases

From: John Sullivan <jsullivan@velocix.com>
Date: Tue, 26 Jun 2012 16:22:59 +0100
Message-ID: <4FE9D3D3.60108@velocix.com>
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.

Received on Tuesday, 26 June 2012 15:23:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:02 UTC