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

Re: WGLC #363: rare cases

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 3 Jul 2012 12:24:18 +1000
Message-Id: <BE4BAFBF-22E7-4681-B562-B048978F9F58@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>
Wrapping this up: I haven't heard any objection to removing this sentence from P6:

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

So I'm scheduling for the next draft.

Cheers,


On 27/06/2012, at 2:01 PM, Mark Nottingham wrote:

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

--
Mark Nottingham   http://www.mnot.net/
Received on Tuesday, 3 July 2012 02:24:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2012 02:24:52 GMT