Re: WGLC #363: rare cases

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.

Cheers,


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

Received on Tuesday, 26 June 2012 23:22:29 UTC