Re: WGLC #363: rare cases

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)

AYJ

Received on Wednesday, 27 June 2012 02:32:31 UTC