RE: Caching dynamic pages (CGI) for one service/server

Henrik wrote:
> Yes, if you have a refresh pattern with a min age other than
> 0. This is
> partly why having such a refresh pattern in strongly discouraged (see
> squid-users achives for earlier discussions). There sould be a note in
> the default squid.conf on this, but I notice there isn't.

This would indeed be a good thing.

 
> This is to allow caching of dateless HTTP/1.0 servers where
> there are no last-modified equivalence.

Perhaps it would be good to make caching of resources without validators
conditional on the absense of a Date: header.

> Query type URLs and POST is explicitly
> excluded from this blind caching in the specification, and may not be
> cached unless there is a cache validator. This exception is assumed to
> catch most dynamic content where caching would hurt, and was
> true before
> the introduction of server side scriptiong (ASP and similar
> techniques).
>
> First refresh pattern of any Squid using refresh patterns
> with a min age
> other than 0 and not using the recommended no_cache rules MUST use the
> following refresh_pattern before any such pattern which
> applies to HTTP
> urls in order to comply with HTTP rules on heuristic expiry
> calculation:
>
> refresh_pattern \? 0 0% 1420
> (the 0% lmfactor can be tuned without any apparent hasard,
> but HTTP/1.1
> requires this to be 0, the max value of 1420 is currently
> unused but may
> prove useful it the change proposed below is made)

Where do you see this? I can't find any reference to the cacheability of
queries. The first paragraph of 13.4 has a bit to say about this situation.

> If there is control directives that denies caching, request type
> indicates uncacheable reply, response code is defined as uncachable or
> if the object requires immediate revalidation (refresh_pattern/expire
> says it is stale) then the object is not cached.

If I read you correctly, I don't think that's quite true (or at least it
shouldn't be); suppose you've got a generated object that requires
revalidation on every hit, but can be validated sucessfully? The way to do
this is:

Expires: [sometime in the past]
Cache-Control: max-age=0, must-revalidate
Last-Modified: [now]

This object *should* be stored, but validated on each subsequent request.

This is a first cut of how I think it may want to be happening...

    # weed out uncacheable requests
    if (CLIENT_MAX_AGE)
        if (AGE > CLIENT_MAX_AGE)
            return STALE
    if (CLIENT_CC_NO_CACHE)
        return STALE

    # weed out uncacheable responses
    if (UNCACHEABLE_METHOD or \
      UNCACHEABLE_STATUS \
      or CC_NO_CACHE)
        return STALE
    if (AGE > OVERRIDE_MAX_AGE)
        return STALE

    # Think about expiration
    if (CC_MAX_AGE or CC_S_MAXAGE or EXPIRES) {
        if (! CC_MUST_REVALIDATE and \
          ! CC_PROXY_REVALIDATE and \
          AGE <= OVERRIDE_MIN_AGE)
            return FRESH
        if (CC_MAX_AGE or CC_S_MAXAGE) {
            if (AGE > CC_MAX_AGE or AGE > CC_S_MAXAGE)
                return STALE
            else
                return FRESH
        }
        if (EXPIRES <= NOW)
            return STALE
        else
            return FRESH
    }

    # Think about validation (no ETags yet)
    if (LAST_MODIFIED) {
        if (LM_FACTOR < PERCENT)
            return FRESH
    }

    # Dateless origin servers
    if (! DATE) {
        if (AGE <= OVERRIDE_MIN_AGE)
            return FRESH
    }

    # fallthrough
    return STALE

I haven't considered Cache-Control: min-fresh and max-stale request headers;
maybe can these be taken care of by fiddling the age? Hmm.
Just noticed something... upon reading 14.9.3, end of first paragraph, a CC:
max-age implies CC: public. Wow.
Received on Wed May 12 1999 - 21:15:59 MDT