Re: mod_cache
--On Friday, March 4, 2005 11:55 PM +0100 Sander Striker [EMAIL PROTECTED]
wrote:
--
modules/cache/mod_cache.c:271
/* If the request has Cache-Control: no-store from RFC 2616, don't store
* unless CacheStoreNoStore is active.
*/
cc_in = apr_table_get(r-headers_in, Cache-Control);
if (r-no_cache ||
(!conf-store_nostore
ap_cache_liststr(NULL, cc_in, no-store, NULL))) {
ap_remove_output_filter(f);
return ap_pass_brigade(f-next, in);
}
What happens if the 'Cache-Control: no-store' header came in with a
304 Not Modified and the original request wasn't conditional?
If I read the spec correctly a 304 can carry a Cache-Control header,
if it has a different value since a previous 200 (or 304).
Hmm. Good point. What a goofy corner case though. I won't lose much sleep
if we don't fix this. Care to add a FIXME? =)
--
modules/cache/mod_cache.c:308
/* have we already run the cachability check and set up the
* cached file handle? */
if (cache-in_checked) {
/* pass the brigades into the cache, then pass them
* up the filter stack
*/
I haven't tracked cache-in_checked fully, so I wonder if it is
possible that this is set on a validating request? That would
cause the cache not being updated, which is what I am trying to
track down FWIW. This is not 'my' bug though, since I am seeing
the following line in the log:
[debug] mod_disk_cache.c(616): disk_cache: Stored headers for URL xxx
However the cache files on disk don't change... I'm a bit puzzled why
not from looking at the code.
Yes, it would be set. in_checked is set after we know that we want to save
the response (i.e. all of the cacheability checks passed successfully).
However, note that if we are 'blocking' the response (i.e. we revalidated the
response succesfully with a 304), we set block_response which is checked right
before in_checked.
(I'll come back to your mod_disk_cache problem at the end.)
--
modules/cache/mod_cache.c:371
/*
* what responses should we not cache?
*
* At this point we decide based on the response headers whether it
* is appropriate _NOT_ to cache the data from the server. There are
* a whole lot of conditions that prevent us from caching this data.
* They are tested here one by one to be clear and unambiguous. */
if (r-status != HTTP_OK r-status != HTTP_NON_AUTHORITATIVE
r-status != HTTP_MULTIPLE_CHOICES
r-status != HTTP_MOVED_PERMANENTLY
r-status != HTTP_NOT_MODIFIED) {
/* RFC2616 13.4 we are allowed to cache 200, 203, 206, 300, 301 or
410
* We don't cache 206, because we don't (yet) cache partial
responses.
* We include 304 Not Modified here too as this is the origin server
* telling us to serve the cached copy.
*/
reason = apr_psprintf(p, Response status %d, r-status);
}
AIUI, we can cache 302 Found (HTTP_MOVED_TEMPORARILY) when it has an
Expires
or Cache-Control indicating that the request can be cached.
Fair enough. Feel free to add it, if you like.
--
modules/cache/mod_cache.c:685
/* Did we just update the cached headers on a revalidated response?
*
* If so, we can now decide what to serve to the client:
* - If the original request was conditional and is satisified, send 304.
* - Otherwise, send the cached body.
*/
if (rv == APR_SUCCESS cache-stale_handle) {
apr_bucket_brigade *bb;
apr_bucket *bkt;
bb = apr_brigade_create(r-pool, r-connection-bucket_alloc);
/* Were we initially a conditional request? */
if (ap_cache_request_is_conditional(cache-stale_headers)) {
/* FIXME: We must ensure that the request meets conditions. */
/* Set the status to be a 304. */
r-status = HTTP_NOT_MODIFIED;
Is this as simple as clearing r-headers_in, overwriting with
cache-stale_headers,
and the calling ap_meets_conditions()?
Yes, I *believe* so. But, we should double-check that ap_meets_condition
would do the 'right' thing. I'm not 100% sure here.
Okay, back to your real bug:
possible that this is set on a validating request? That would
cause the cache not being updated, which is what I am trying to
track down FWIW. This is not 'my' bug though, since I am seeing
the following line in the log:
[debug] mod_disk_cache.c(616): disk_cache: Stored headers for URL xxx
However the cache files on disk don't change... I'm a bit puzzled why
not from looking at the code.
Please correct me if I'm wrong. My understanding is that you have an expired
cache entry which needs to be revalidated and the updated headers aren't
updating properly.
Now that I read the code I'm betting you are hitting that else block with 'XXX
log message' in mod_disk_cache's store_headers. The sequence that I'm
envisioning is:
- We have a stale cached entity/handle.
- We send an If-Modified-Since/etc request
- We get the 304
Re: Multiple AAA providers
--On Friday, March 4, 2005 12:42 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: We have a naming problem. Provider is meaningless. No, it's not. It's directly from the code and API itself. See ap_provider.h. Is a provider Basic, Digest? No. These are the auth mechanisms which *call* providers. Or is a provider File, DBM, LDAP? Yes. If you mean the former, I'm right there with you. However, that won't work on antique (2.0, even 1.3) auth modules, so my concept is still valid. It should simply be replaced for httpd-2.0 with something clearer :) Well, obviously, you're not with me here. =) -- justin
Re: svn commit: r156274 - in httpd/httpd/trunk: CHANGES include/ap_mmn.h include/scoreboard.h modules/generators/mod_status.c server/mpm/worker/worker.c
On Mar 5, 2005, at 12:06 PM, [EMAIL PROTECTED] wrote: Modified: httpd/httpd/trunk/include/ap_mmn.h URL: http://svn.apache.org/viewcvs/httpd/httpd/trunk/include/ap_mmn.h? view=diffr1=156273r2=156274 === === --- httpd/httpd/trunk/include/ap_mmn.h (original) +++ httpd/httpd/trunk/include/ap_mmn.h Sat Mar 5 12:06:55 2005 @@ -92,6 +92,7 @@ * 20050217.0 (2.1.3-dev) Axed find_child_by_pid, mpm_*_completion_context (winnt mpm) *symbols from the public sector, and decorated real_exit_code *with ap_ in the win32 os.h. + * 20050305.0 (2.1.4-dev) added pid and generation fields to worker_score */ #define MODULE_MAGIC_COOKIE 0x41503230UL /* AP20 */ This doesn't seem to have an actual MMN bump, just the mention of one. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r156279 - httpd/httpd/trunk/include/ap_mmn.h
On Sat, 05 Mar 2005 20:39:33 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: trawick Date: Sat Mar 5 12:39:32 2005 New Revision: 156279 Submitted by: Sander Striker oops, I put the wrong Sander too :(
Re: svn commit: r156279 - httpd/httpd/trunk/include/ap_mmn.h
Jeff Trawick wrote: On Sat, 05 Mar 2005 20:39:33 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: trawick Date: Sat Mar 5 12:39:32 2005 New Revision: 156279 Submitted by: Sander Striker oops, I put the wrong Sander too :( Good thing you can fix log messages with svn (Hint: svn propset --revprop svn:log -r 156279 ) Sander
Re: svn commit: r156279 - httpd/httpd/trunk/include/ap_mmn.h
On Sat, 05 Mar 2005 21:48:15 +0100, Sander Striker [EMAIL PROTECTED] wrote: Don't confuse me again ;) Jeff Trawick wrote: On Sat, 05 Mar 2005 20:39:33 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: trawick Date: Sat Mar 5 12:39:32 2005 New Revision: 156279 Submitted by: Sander Striker oops, I put the wrong Sander too :( Good thing you can fix log messages with svn (Hint: svn propset --revprop svn:log -r 156279 ) Thanks for the hint!
Re: svn commit: r156274 - in httpd/httpd/trunk: CHANGES include/ap_mmn.h include/scoreboard.h modules/generators/mod_status.c server/mpm/worker/worker.c
* Sander Temme wrote: This doesn't seem to have an actual MMN bump, just the mention of one. It breaks binary compat, doesn't it? So I think, the bump is correct. nd -- Winnetous Erbe: http://pub.perlig.de/books.html#apache2
Re: svn commit: r156274 - in httpd/httpd/trunk: CHANGES include/ap_mmn.h include/scoreboard.h modules/generators/mod_status.c server/mpm/worker/worker.c
On Sat, 5 Mar 2005 22:16:47 +0100, André Malo [EMAIL PROTECTED] wrote: * Sander Temme wrote: This doesn't seem to have an actual MMN bump, just the mention of one. It breaks binary compat, doesn't it? So I think, the bump is correct. the problem was that in my original commit, I described the change in a comment but didn't actually modify the MMN ;)
Re: Multiple AAA providers
At 11:54 AM 3/5/2005, Justin Erenkrantz wrote: --On Friday, March 4, 2005 12:42 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Or is a provider File, DBM, LDAP? Yes. [...] obviously, you're not with me here. =) -- justin Ok, as Justin and I are in significant disagreement ... to summarize; we (collectively) would like to see some mechanism for multiple configurations of the same 'provider' (defined above). There are logically three places this can happen, so as a straw poll, would those interested in *coding* auth schemas please vote (end users, our choice will be transparent enough to you that we prefer the developers to indicate their preferences.) [ ] Implement in each provider (e.g. mod_authnz_ldap, mod_authn_file) Different AuthLdapConfig xxx AuthFileConfig zzz sections [ ] Implement in each scheme (e.g. basic, digest) Different AuthBasicConfig xxx AuthDigestConfig zzz sections [ ] Implement globally across schemes and providers Single AuthConfig xxx directive, but as it's not in the scheme which iterates the providers, control isn't as fine-grained. Please comment. Bill
