W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2007

Re: Updating Entity Headers with 304s

From: Mark Nottingham <mnot@mnot.net>
Date: Sun, 11 Feb 2007 08:35:52 +1100
Message-Id: <FC11C2E6-1C3A-4D4D-8F3B-AA0EC14BFDB4@mnot.net>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
To: Roy T. Fielding <fielding@gbiv.com>

Hi Roy,

Ah, I'm not familiar with mod_jk; does it have its own protocol to  
communicate from the front-end to the back-end?

> Here's the configuration:  Frontend reverse caching proxy server  
> running httpd
> 2.2.2, prefork mpm.  The backend web server is httpd 1.3.36 with  
> mod_jk 1.2.15.

Also, this fix was sold in the 2.2.2 notes as a change/fix to  
mod_cache (which is what piqued my interest in the first place);

>   *) mod_cache: Do not overwrite the Content-Type in the cache, for
>      successfully revalidated cached objects. PR 39647.

Are you saying that mod_cache, when used with a HTTP back-end, *will*  
replace the Content-Type if a 304 contains a new one?



On 2007/02/11, at 7:30 AM, Roy T. Fielding wrote:

> On Feb 9, 2007, at 9:41 PM, Mark Nottingham wrote:
>> However, an implementer has interpreted the stated intent to mean  
>> that a cache should not allow entity headers to be updated by  
>> 304s. See: <http://issues.apache.org/bugzilla/show_bug.cgi?id=39647>.
>
> The problem report is about the internal handling of a gateway  
> response
> that doesn't even use HTTP, so the text in the spec doesn't apply
> except in the most abstract sense.
>
>> There's a certain logic to both positions. Does anyone recall what  
>> the original intent was, and do we need a clarification here?
>
> The intent is that the refreshed cache entry matches what would  
> have been
> sent in a 200 response.  Anything else would be considered an error.
>
> In this case, the back-end has an error that is generating a text/html
> response intermittently, and the unset that Ruediger added is just  
> making
> sure that the cache filter doesn't interpret the response incorrectly.
> The right solution is to just fix mod_jk, and I think that was done as
> well, since masking a back-end error is a bad idea.  mod_jk does  
> not use
> HTTP, so the specification does not apply.
>
> ....Roy


--
Mark Nottingham     http://www.mnot.net/
Received on Saturday, 10 February 2007 21:36:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:00 GMT