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

Re: WGLC #363: rare cases

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 27 Jun 2012 09:22:00 +1000
Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <2B59E8BE-F3C9-4931-BE3F-D3E763A12832@mnot.net>
To: John Sullivan <jsullivan@velocix.com>

On 27/06/2012, at 1:22 AM, John Sullivan wrote:

> 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.

Those are reasons not to generate a LM, but they aren't specific to HTTP/1.0 -- agreed?

I can see dropping the last sentence and qualifying the remaining SHOULD with these sorts of reasons, but not retaining it.


Mark Nottingham   http://www.mnot.net/
Received on Tuesday, 26 June 2012 23:22:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:00 UTC