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 :-) (http://svn.apache.org/viewvc?view=rev&revision=152973). >> 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 accordingly. 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? Regards Rüdiger
