Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <464CE3DB.9040206@apache.org>
Date: Fri, 18 May 2007 01:23:07 +0200
From: Ruediger Pluem <rpluem@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060417
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: svn commit: r539063 - in /httpd/httpd/trunk: CHANGES
 modules/cache/mod_cache.c
References: <20070517182515.57DC71A983E@eris.apache.org>
 <464CBF2E.1000003@apache.org>
 <5c902b9e0705171356m4d2fbb80g22e0122c8b46036@mail.gmail.com>
 <464CCB8C.4090109@apache.org>
 <5c902b9e0705171453q6729315dp584d1309e423e13e@mail.gmail.com>
 <5786CA45-CA4B-403F-AFEB-A959087E4418@gbiv.com>
In-Reply-To: <5786CA45-CA4B-403F-AFEB-A959087E4418@gbiv.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit


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