Mailing-List: contact bugs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache HTTPD Bugs Notification List" <bugs@httpd.apache.org>
From: bugzilla@apache.org
To: bugs@httpd.apache.org
Subject: DO NOT REPLY [Bug 35247]  - cache ignores s-maxage (in responses with
 max-age)
In-Reply-To: <bug-35247-7868@http.issues.apache.org/bugzilla/>
Message-Id: <20060606014111.A284C7142A1@brutus.apache.org>
Date: Tue,  6 Jun 2006 01:41:11 +0000 (GMT)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=35247>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35247


------- Additional Comments From hno@squid-cache.org  2006-06-06 01:41 -------
> That implies to me that if s-maxage is set, it should also override any
> max-age passed in the request. If s-maxage only is supposed to override 
> max-age in the cached response, then a slightly more complicated fix would
> be needed.

Not quite.

Neither change the meaning of the request max-age. It's a separate condition all
together.

If CC s-maxage is set in the response then this overrides any Expires and/or CC
max-age in the response header and their values are not relevant for the
expiry/freshness calculation.

If CC max-age is set in the response then this overrides any Expires response
header and the Expires header is not relevant for the expiry/freshness calculation. 

The reasoning behind this is to allow the content provided to tune caching
appropriately. There is situations where one wants shared caches to cache longer
than private caches, and there is siuations where the shared cache should cache
a shorter interval. Expires is the HTTP/1.0 fallback, and should consequently be
ignored if any of the HTTP/1.1 constraints is available (max-age or s-maxage).


However, CC max-age request header rmust also be respected in all conditions.
There is no response headers which overrides this request header.


There is no s-maxage request CC directive, as it would be kind of pointless to
define a such directive.


There is however a the max-stale request directive which can relax the freshness
checks, but not if any of the must-revalidate conditions is set on the response
(must-revalidate, s-maxage, proxy-revalidate, no-cache). If any of the
must-revalidate conditions is set then stale objects must be revalidated with
the origin before sent to the requesting client.


response s-max-age / max-age / expires (in that order) sets the server side
freshness expiry date.

if neither s-max-age / max-age or expires is present then heuristics MAY be used
to assign an freshness expiry date on the response.

request max-age sets the client-side upper limit on the freshness expiry date
ontop of the freshness expiry defined by the origin.

after this request max-stale applies and defines how far after the freshness
expiry date is considered acceptable by the client. The cache MAY send such
stale responses.


And yes, I do consider myself an expert on HTTP.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org