From: verdy_p (verdy_p@wanadoo.fr)
Date: Thu Jan 21 2010 - 07:56:51 CST
"Jon Hanna" wrote:
> Brett Zamir wrote:
> > I don't see any
> > indication in the MDC documentation that the browser should store fonts
> > it finds indefinitely (or unless the font is modified).
>
> I would generally consider that to be inherent to the rules for caching
> as defined in RFC 2616 for cases where HTTP is used for the download
> (which I imagine would be the norm).
Yesn but RFC 2616 does NOT mandate an infinite lifetime in caches, and does not even mandate the effective use of
any cache. This RFC just determines the ***maximum** validity of data in caches, if they are present and this
maximum is specified in the returned HTTP results.
When the HTTP request results does not specify any maximum, it's up to the client requesting that resources to
determine which maximum lifetime it will use, because the default maximum is possibly infinite (but it can safely
use a zero lifetime for the cached data, i.e. no cache at all).
There are several factors that can change the lifetime of caches, but the rule os that you can ONLY reduce the
lifetime, but you annot extend it.
Some types of requests are oalso not cachable by default (notably the results of POST and PUT requests). GET and
STAT requests are cachable by default, unless there are cache-control headers in the HTTP reply.
This RFC also does not mandate any minimum size for the cache: even though a result is specified as cachable, the
client (or any intermediate proxy) may opt to not cache it at all if it exceeds some size threshold or the maximum
capacity of its local cache.
But one thing is true: by default, caches are possible in HTTP/1.1 (and very safe if implemented correctly by both
servers and clients fully complying to the RFC 2616).
Depending on caches with the legacy HTTP/1.0 is not secured enough to be valid (HTTP/1.0 is not very well defined by
a standard, but just defined weakly by some compatibility practices not always followed, as HTTT/1.0 dosr not
correctly specify things like sessions, cacheability, support for fragmented output, retrieval from arbitrary
positions, negociation of recipient and server capabilities and accepted formats and transport syntaxes or
compressions, support for "virtual servers" hosting multiple domains with distinct ressources on the same host, and
so on...).
Philippe.
This archive was generated by hypermail 2.1.5 : Thu Jan 21 2010 - 07:59:33 CST