- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 3 Jul 2012 12:38:08 +1000
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Cc: "Julian F. Reschke" <julian.reschke@gmx.de>, Amos Jeffries <squid3@treenet.co.nz>
I haven't heard any more discussion of this. As it is, we have a proposal to close this issue: > Add a note to <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#calculating.freshness.lifetime>: > > """ > When there is more than one value present for a given directive (e.g., two Expires headers, multiple Cache-Control: max-age directives), it is considered invalid. Caches SHOULD consider responses that have invalid freshness information to be stale. > """ Feedback? Regards, On 21/06/2012, at 1:35 PM, Mark Nottingham wrote: > On 12/06/2012, at 10:19 AM, Amos Jeffries wrote: > >> On 12.06.2012 01:20, Julian Reschke wrote: >>> On 2012-06-11 15:04, Amos Jeffries wrote: >>>> ... >>>> * flag parameters can't exactly contradict, so dropping/merging >>>> duplicates and treating as one flag would seem okay. (only-if-cached >>>> must-revalidate, proxy-ravalidate, no-cache, no-store, no-transform, etc) >>> >>> "public" vs "private"? >> >> Okay. Nasty case there. >> "public" is specifically linked to the auth systems though isn't it? >> >> Can we safely assume that "private" on auth responses is invalid and that "public" was intended to override it? >> >> on non-auth responses "public" would seem to be the redundant state, and "private" assumed to be the desired behaviour? > > Why are we trying to design a general solution to this problem? > > The current spec already deals with these cases; follow the rules in <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#response.cacheability> and <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#constructing.responses.from.caches> and the precedence should be clear. > > >>>> * time-delta parameters (max-age, s-maxage, etc) being conservative and >>>> dropping the larger or equal of the two seems the right handling. >>> >>> Yes, we could say that. > > And indeed, there's already a proposal on the table here: > >> Add a note to <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#calculating.freshness.lifetime>: >> >> """ >> When there is more than one value present for a given directive (e.g., two Expires headers, multiple Cache-Control: max-age directives), it is considered invalid. Caches SHOULD consider responses that have invalid freshness information to be stale. >> """ > > The SHOULD and <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#intro.conformance.and.error.handling> give implementations enough flexibility to recover if they wish, but I personally don't think we want to specify a particular behaviour here, because we'll very likely make current implementations non-conforming. Happy to talk through this one, though. > > >>>> * list of tokens ... maybe combine? it is possible one proxy adds >>>> no-cache="Foo" and another adds no-cache="Bar" and they both hit some >>>> downstream cache which needs to handle both Foo and Bar properly. >>>> Yes the right thing to do woudl have been no-cache="Foo Bar". But >>>> what if that is not done? >>> >>> Right now we allow >>> >>> no-cache="Foo, Bar" >>> >>> Should >>> >>> no-cache="Foo", no-cache="Bar" >>> >>> be equivalent? (That would be similar with the use of list syntax in >>> header fields) >> >> I think so, yes. > > > Given that this isn't widely used, I don't have a big problem with defining something here, but I do wonder if we're getting to diminishing returns. > > Can someone please make a proposal? > > Thanks, > > -- > Mark Nottingham http://www.mnot.net/ > > > > -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 3 July 2012 02:38:35 UTC