- From: Paul Leach <paulle@microsoft.com>
- Date: Wed, 10 Apr 1996 16:51:18 -0700
- To: "'Jeffrey Mogul'" <mogul@pa.dec.com>
- Cc: "'http-caching@pa.dec.com'" <http-caching@pa.dec.com>
You're right -- it's an issue of the easiest to understand and implement encoding. Henry's proposal is at least easier to implement when you always obey the max-age sent by the origin-server, and don't allow preferences for overriding it. And I think it may be less likely to confuse -- you basically say that if the user-preference setting says to not validate when max-age is 0, then each time max-age=0 is seen, the user has to give premission to skip the revalidation. >---------- >From: Jeffrey Mogul[SMTP:mogul@pa.dec.com] >Sent: Wednesday, April 10, 1996 3:32 PM >To: Paul Leach >Cc: 'http-caching@pa.dec.com' >Subject: Re: Must-revalidate [was Re: Warning: header, need origin] > > Henry Sanders made an interesting suggestion to me -- what if we >made > max-age=0 always mandatory (same as proposed "must-validate", but >told > people to use max-age=1 when it was (barely) acceptable for >end-user > caches to violate it. > > Not revalidating when max-age is 0 would require a dialog box each >time > for the user to approve; not validating for max-age > 0 could be >done > with a preference setting. > > This way, a user-agent that just wanted to strictly obey the > origin-server's max-age request could just ignore this whole issue. > >I think we (except probably for Roy) are basically nit-picking about >an encoding scheme. Henry's proposal seems to be that > > max-age=NNNN > (1) what I meant by "must-revalidate" if NNNN == 0 > > (2) what we've already defined for max-age=NNNN for NNNN > 0 > >I'm not sure if this is any easier (or harder) to implement than >my proposal. It won't make the spec a lot shorter (since the >two different semantics will still have to be explained). It makes >the list of cache-control directives one entry shorter. It makes >it slightly more likely that someone will be confused about the >meaning of max-age (since it has this somewhat odd shift). > >-Jeff >
Received on Thursday, 11 April 1996 00:23:11 UTC