Re: Updating Entity Headers with 304s

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 UTC