Re: Auto-retrieving Unicode fonts from centralized server in absence of @font-face or built-in support

From: verdy_p (
Date: Thu Jan 21 2010 - 07:56:51 CST

  • Next message: Petr Tomasek: "Re: Aramaic speech and script"

    "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...).


    This archive was generated by hypermail 2.1.5 : Thu Jan 21 2010 - 07:59:33 CST