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
