On 05/17/2007 10:56 PM, Justin Erenkrantz wrote:
> On 5/17/07, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
>
>> > + x = apr_atoi64(max_age_val);
>> > + if (errno) {
>> > + x = conf->defex;
>>
>> Hm. Shouldn't we adjust the bogus max-age field value in the
>> Cache-Control header in r->headers_out
>> / r->err_headers_out to conf->defex (in seconds of course) in this case?
>
>
> I thought about doing that - but I came to the idea that our local
> cache is doing its own validation, but it shouldn't make its local
> expiration decisions binding upon downstream requestors - i.e. it
But it already does in the case of the Expires header. If the Expires
header is missing or bogus and no max-age field is present (valid or invalid),
we set one with the expires date the cache calculated (either heuristic or
default). And this creates the next question for me: Why always use the default
expire setting in the case of a bogus max-age? In the case of a bogus Expire
header we try to calculate a heuristic expiration date using the Last-Modified
header (if present and valid).
I think we should handle Expires and max-age in the same way here.
> shouldn't tweak the value under any circumstances.
>
> I can be convinced that's the wrong approach and that we should indeed
> normalize it in the event of an error, but my gut says letting is just
> pass-through seems right. -- justin
But shouldn't the client have the same expiration expectation as the cache?
In the case of an invalid max-age field I would see it as a correct decision
by a client to ignore it completely for its local cache and thus possibly
do not cache it at all.
Regards
Rüdiger
