httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject Re: svn commit: r539063 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_cache.c
Date Thu, 17 May 2007 23:23:07 GMT

On 05/18/2007 12:19 AM, Roy T. Fielding wrote:
> On May 17, 2007, at 2:53 PM, Justin Erenkrantz wrote:
>> BTW, I'm not a fan of us inventing Expires headers in this section of

I don't want to pick on you, but ironically it was you who introduced this :-)

>> code - I'd think it'd be far cleaner to off-load Expires response
>> header generation to mod_expires and leave the cache out of it
>> entirely - inventing Expires values deep inside of mod_cache seems
>> unclean.  mod_cache, IMO, should just respect what it is told and not
>> change how things appear to downstream folks.  (mod_expires is more
>> than capable of inserting in the Expires header if the admin wants
>> it.)
> I agree -- caches are not allowed to invent header fields like Expires.
> They can only do so by explicit override in the configuration 
> (mod_expires).
> Setting Expires here is wrong.  Changing max-age would be even worse.
> Age is the only thing the cache should be setting.
>> Does my position make sense?  I'm of the opinion that we should go one
>> of two ways:
>> - mod_cache shouldn't touch the response - so it stops setting Expires
>> or anything like that which affects cachability
> +1

Ok. So we should remove the

apr_rfc822_date(expire_hdr, exp);
apr_table_set(r->headers_out, "Expires", expire_hdr);

lines there.
Just for clarification: It is still ok for us to define an cache internal expiration
date (default / calculated) if there is nothing valid (max-age, Expires) in the
response, right?
We just do not tell the client about it as we do not adjust the headers in the response
BTW: What about s-max-age here? Shouldn't we use s-maxage instead of max-age in the
case it is present in the response?



View raw message