httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: [PATCH] mod_disk_cache: Handling of Varied Content
Date Sun, 12 Jun 2005 17:37:38 GMT
On Sun, Jun 12, 2005 at 10:06:30AM -0700, Paul Querna wrote:
> I believe so.  Yes, it clutters the code, but my objective is to have a 
> switch where I can easily add logging to the common case code, and leave 
> it in there, instead of deleting it before I commit.  I think in the 
> long run, we need a different log level for 'developer' debugging.  Just 
> look at some of the stuff that the a reverse SSL Proxy logs at LogLevel 
> Debug.

I would really prefer that we stick with placing these log entries at debug
and address a 'developer' log level independently of this.  But, adding
#ifdefs is not a solution.

> ap_get_list_item() returns them lower-cased, avoiding this whole issue.

Relying on lowercased header names is not enough.  In certain cases, the
header *values* are supposed to be rendered case-insensitively as well
(Accept-Encoding, etc.).  Yet, in other cases, the header values are supposed
to be case-sensitive.  =)

This will mean that the cache will not hit when it should.  We *could* just
punt on the values and cache multiple responses that are actually the same...

> >This probably should call apr_file_remove first.
> 
> I disagree.  It should not.  Calling apr_file_remove first creates a 
> wider window when the .vary file does not exist.  If anywhere, it should 
> be called right before _rename(), but why even call it there, when 
> rename will replace it atomically?

Hmm.  I guess APR makes a guarantee that it'll always overwrite the file (even
though many platforms don't do that in their rename call - i.e. Win32).  So,
we should probably yank the other _remove calls then?

> >There is also a degenerate case here: a response wasn't previously using 
> >Vary
> >but now is or vice versa.  We should see about clearing out any datafile 
> >and
> >hdrsfile (or varyfile if no longer present) before continuing on.
> > 
> >
> 
> Case #1:  URL added a Vary Header.
> This should be work fine.  The .header and .data files should be cleaned 
> up by htcacheclean like normal URLs.  If we switched to .header files 
> for the Vary headers, we would need something to cleanup the .data file. 
> (htcacheclean modification?)

I'd prefer that we be clean here and _remove() the .data file then.
htcacheclean won't prune orphan .data files - it needs the .header file now.

> Case #2: URL stops sending the Vary header.
> Problem.  In this case we should remove the .vary file.  However, if we 
> changed the code to store the vary info in the .header file, this case 
> would work fine, since it would overwrite the .header file with Vary 
> info, with one without vary info, and fix this issue.

Correct.  That's a nice side-effect of using the .header file.  =)  -- justin

Mime
View raw message