RE: [squid-users] Expires: vs. Cache-Control: max-age
According to HTTP/1.1 specification, the precedence is not determined by the keyword, but by the value: The shorter age is to be taken. Regards Markus > -Original Message- > From: Chris Woodfield [mailto:[EMAIL PROTECTED] > Sent: Freitag, 26. September 2008 23:46 > To: Squid Users > Subject: [squid-users] Expires: vs. Cache-Control: max-age > > Hi, > > Can someone confirm whether Expires: or Cache-control: max-age > parameters take precedence when both are present in an object's > headers? My assumption would be Cache-control: max-age would be > preferred, but we're seeing some behavior that suggests otherwise. > > Specifically, we're seeing Expires: headers in the past resulting in > refresh checks against our origin even when a Cache-Control: max-age > header is present and the cached object should be fresh per that > metric. > > What we're seeing is somewhat similar to bug 2430, but I want to make > sure what we're seeing isn't expected behavior. > > Thanks, > > -Chris
Re: [squid-users] Expires: vs. Cache-Control: max-age
No, that's not true. RFC2616: 13.2.4 Expiration Calculations In order to decide whether a response is fresh or stale, we need to compare its freshness lifetime to its age. The age is calculated as described in section 13.2.3; this section describes how to calculate the freshness lifetime, and to determine if a response has expired. In the discussion below, the values can be represented in any form appropriate for arithmetic operations. We use the term "expires_value" to denote the value of the Expires header. We use the term "max_age_value" to denote an appropriate value of the number of seconds carried by the "max-age" directive of the Cache-Control header in a response (see section 14.9.3). The max-age directive takes priority over Expires, so if max-age is present in a response, the calculation is simply: freshness_lifetime = max_age_value Otherwise, if Expires is present in the response, the calculation is: freshness_lifetime = expires_value - date_value and later: 14.9.3 Modifications of the Basic Expiration Mechanism The expiration time of an entity MAY be specified by the origin server using the Expires header (see section 14.21). Alternatively, it MAY be specified using the max-age directive in a response. When the max-age cache-control directive is present in a cached response, the response is stale if its current age is greater than the age value given (in seconds) at the time of a new request for that resource. The max-age directive on a response implies that the response is cacheable (i.e., "public") unless some other, more restrictive cache directive is also present. If a response includes both an Expires header and a max-age directive, the max-age directive overrides the Expires header, even if the Expires header is more restrictive. This rule allows an origin server to provide, for a given response, a longer expiration time to an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This might be useful if certain HTTP/1.0 caches improperly calculate ages or expiration times, perhaps due to desynchronized clocks. I.e., the max-age cache-control directive takes precedence over Expires. I've tested Squid and a number of other caches with Co-Advisor, and if Expires indicates the response is fresh, but CC: max-age says it's stale, it will treat it as stale, for just about any given cache. Unfortunately, Co-Advisor doesn't test the reverse situation, although I may have overlooked it (Alex?). On 27/09/2008, at 4:44 PM, Markus Karg wrote: According to HTTP/1.1 specification, the precedence is not determined by the keyword, but by the value: The shorter age is to be taken. Regards Markus -Original Message- From: Chris Woodfield [mailto:[EMAIL PROTECTED] Sent: Freitag, 26. September 2008 23:46 To: Squid Users Subject: [squid-users] Expires: vs. Cache-Control: max-age Hi, Can someone confirm whether Expires: or Cache-control: max-age parameters take precedence when both are present in an object's headers? My assumption would be Cache-control: max-age would be preferred, but we're seeing some behavior that suggests otherwise. Specifically, we're seeing Expires: headers in the past resulting in refresh checks against our origin even when a Cache-Control: max-age header is present and the cached object should be fresh per that metric. What we're seeing is somewhat similar to bug 2430, but I want to make sure what we're seeing isn't expected behavior. Thanks, -Chris -- Mark Nottingham [EMAIL PROTECTED]
Re: [squid-users] Expires: vs. Cache-Control: max-age
On Wed, 2008-10-01 at 15:42 +1000, Mark Nottingham wrote: > No, that's not true. RFC2616: > > > 13.2.4 Expiration Calculations > > In order to decide whether a response is fresh or stale, we need to > > compare its freshness lifetime to its age. The age is calculated as > > described in section 13.2.3; this section describes how to calculate > > the freshness lifetime, and to determine if a response has expired. > > In the discussion below, the values can be represented in any form > > appropriate for arithmetic operations. > > > > We use the term "expires_value" to denote the value of the Expires > > header. We use the term "max_age_value" to denote an appropriate > > value of the number of seconds carried by the "max-age" directive of > > the Cache-Control header in a response (see section 14.9.3). > > > > The max-age directive takes priority over Expires, so if max-age is > > present in a response, the calculation is simply: > > > > freshness_lifetime = max_age_value > > Otherwise, if Expires is present in the response, the calculation is: > > > > freshness_lifetime = expires_value - date_value > > and later: > > > 14.9.3 Modifications of the Basic Expiration Mechanism > > The expiration time of an entity MAY be specified by the origin > > server using the Expires header (see section 14.21). Alternatively, > > it MAY be specified using the max-age directive in a response. When > > the max-age cache-control directive is present in a cached response, > > the response is stale if its current age is greater than the age > > value given (in seconds) at the time of a new request for that > > resource. The max-age directive on a response implies that the > > response is cacheable (i.e., "public") unless some other, more > > restrictive cache directive is also present. > > > > If a response includes both an Expires header and a max-age > > directive, the max-age directive overrides the Expires header, even > > if the Expires header is more restrictive. This rule allows an > > origin server to provide, for a given response, a longer expiration > > time to an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This > > might be useful if certain HTTP/1.0 caches improperly calculate ages > > or expiration times, perhaps due to desynchronized clocks. > > > > I.e., the max-age cache-control directive takes precedence over Expires. > I've tested Squid and a number of other caches with Co-Advisor, and if > Expires indicates the response is fresh, but CC: max-age says it's > stale, it will treat it as stale, for just about any given cache. > Unfortunately, Co-Advisor doesn't test the reverse situation, although > I may have overlooked it (Alex?). I am sorry, I am not sure what you mean by the "reverse situation". Expires indicates stale but max-age says fresh? If not, can you specify it explicitly? Thank you, Alex. > On 27/09/2008, at 4:44 PM, Markus Karg wrote: > > > According to HTTP/1.1 specification, the precedence is not > > determined by > > the keyword, but by the value: The shorter age is to be taken. > > > > Regards > > Markus > > > >> -Original Message- > >> From: Chris Woodfield [mailto:[EMAIL PROTECTED] > >> Sent: Freitag, 26. September 2008 23:46 > >> To: Squid Users > >> Subject: [squid-users] Expires: vs. Cache-Control: max-age > >> > >> Hi, > >> > >> Can someone confirm whether Expires: or Cache-control: max-age > >> parameters take precedence when both are present in an object's > >> headers? My assumption would be Cache-control: max-age would be > >> preferred, but we're seeing some behavior that suggests otherwise. > >> > >> Specifically, we're seeing Expires: headers in the past resulting in > >> refresh checks against our origin even when a Cache-Control: max-age > >> header is present and the cached object should be fresh per that > >> metric. > >> > >> What we're seeing is somewhat similar to bug 2430, but I want to make > >> sure what we're seeing isn't expected behavior. > >> > >> Thanks, > >> > >> -Chris > > -- > Mark Nottingham [EMAIL PROTECTED] >
Re: [squid-users] Expires: vs. Cache-Control: max-age
On 02/10/2008, at 3:37 PM, Alex Rousskov wrote: I.e., the max-age cache-control directive takes precedence over Expires. I've tested Squid and a number of other caches with Co-Advisor, and if Expires indicates the response is fresh, but CC: max-age says it's stale, it will treat it as stale, for just about any given cache. Unfortunately, Co-Advisor doesn't test the reverse situation, although I may have overlooked it (Alex?). I am sorry, I am not sure what you mean by the "reverse situation". Expires indicates stale but max-age says fresh? If not, can you specify it explicitly? Thank you, Alex. Yes, that's it. Cheers, -- Mark Nottingham [EMAIL PROTECTED]
Re: [squid-users] Expires: vs. Cache-Control: max-age
On ons, 2008-10-01 at 15:42 +1000, Mark Nottingham wrote: > I.e., the max-age cache-control directive takes precedence over Expires. > I've tested Squid and a number of other caches with Co-Advisor, and if > Expires indicates the response is fresh, but CC: max-age says it's > stale, it will treat it as stale, for just about any given cache. Correct. Squid ignores Expires if there is a CC max-age response directive. See HttpReply::hdrExpirationTime() / httpReplyHdrExpirationTime(). Regards Henrik signature.asc Description: This is a digitally signed message part
