- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 3 Jul 2012 12:24:18 +1000
- 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 UTC