Re: WGLC #363: rare cases

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

Cheers,


--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 27 June 2012 04:02:25 UTC