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 14:01:56 +1000
Cc: <ietf-http-wg@w3.org>
Message-Id: <21E89BD2-7C7E-45E4-9537-34ED6956D55B@mnot.net>
To: Amos Jeffries <squid3@treenet.co.nz>

On 27/06/2012, at 12:32 PM, Amos Jeffries wrote:

> On 27.06.2012 11:22, Mark Nottingham wrote:
>> 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.
> This bit ...
>>> 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.
> ... seems to be repeating the "rare cases" clause. Again with no supporting evidence for its existence, or identifiable way the origin might know about *future* downstream caching decisions.
> To me the clause looks like dependence on the "evil bit" or equivalent being sent.
> Although if the request was sent with a Date: which was noticeably out of sync with the servers own clock or some IMS timestamp in the future. Those could be a sign that the downstream is not able to depend on timestamps like LM properly. But I wouldn't bet on that either with the clockless algorithms.
> Drawing at straws here it may be referring to the (hopefully rare) case of a server being required to add a Date: to a response with Last-Modified already in place? (ie CGI script created hedes being processed by an origin).
> In that case would it be better to add the Date and drop the Last-Modified? or simply not add the Date? (violating part 2 section 10.2)

I think this is getting into error-handling territory (inside the same implementation!).

I think we should just remove the last sentence. We already contextualise it:

Origin servers SHOULD send Last-Modified for any selected representation for which a last modification date can be reasonably and consistently determined...


Mark Nottingham   http://www.mnot.net/
Received on Wednesday, 27 June 2012 04:02:25 UTC

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