The issue below came up again in PR21260. So anyone with an idea now if this is a bug in the documentation or in the code?
Regards RĂ¼diger On 01/17/2006 02:11 PM, Ruediger Pluem wrote: > I found a difference between the documentation of CacheMaxExpire and the code. > The documentation of CacheMaxExpire says: > > "This maximum value is enforced even if an expiry date was supplied with the > document." > > Looking at the code I found: > > /* if no expiry date then > * if lastmod > * expiry date = date + min((date - lastmod) * factor, maxexpire) > * else > * expire date = date + defaultexpire > */ > if (exp == APR_DATE_BAD) { > char expire_hdr[APR_RFC822_DATE_LEN]; > > /* if lastmod == date then you get 0*conf->factor which results in > * an expiration time of now. This causes some problems with > * freshness calculations, so we choose the else path... > */ > if ((lastmod != APR_DATE_BAD) && (lastmod < date)) { > apr_time_t x = (apr_time_t) ((date - lastmod) * conf->factor); > > if (x > conf->maxex) { > x = conf->maxex; > } > exp = date + x; > apr_rfc822_date(expire_hdr, exp); > apr_table_set(r->headers_out, "Expires", expire_hdr); > } > else { > exp = date + conf->defex; > apr_rfc822_date(expire_hdr, exp); > apr_table_set(r->headers_out, "Expires", expire_hdr); > } > } > info->expire = exp; > > So CacheMaxExpire only applies if no valid expire date was delivered with the > document. > Furthermore CacheDefaultExpire can be larger than CacheMaxExpire. > > The question that remains: It this a bug in the code or in the documentation? >