[STATUS] (httpd-2.1) Wed Aug 4 23:45:14 EDT 2004
APACHE 2.1 STATUS: -*-text-*- Last modified at [$Date: 2004/04/27 22:09:17 $] Release [NOTE that only Alpha/Beta releases occur in 2.1 development]: 2.1.0 : in development Please consult the following STATUS files for information on related projects: * srclib/apr/STATUS * srclib/apr-util/STATUS * docs/STATUS Contributors looking for a mission: * Just do an egrep on "TODO" or "XXX" in the source. * Review the "PatchAvailable" bugs in the bug database. Append a comment saying "Reviewed and tested". * Open bugs in the bug database. CURRENT RELEASE NOTES: * When the CVS->SVN is done, there's a bogus avendor branch that should be removed from most files. The branch was created 4/27/2004. It's safest (and easiest) for now just to leave it in there; the MAIN branch and the APACHE_2_0_BRANCH are untouched and unharmed. --jwoolley RELEASE SHOWSTOPPERS: * Handling of non-trailing / config by non-default handler is broken http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105451701628081&w=2 * the edge connection filter cannot be removed http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105366252619530&w=2 CURRENT VOTES: * Promote mod_cache from experimental to non-experimental status (keep issues noted below in EXPERIMENTAL MODULES as items to be addressed as a supported module). +1: jim, bnicholes -0: jerenkrantz -1: stoddard There are a couple of problems that need to be resolved before this module is moved out of experimental. 1) We need to at least review and comment on the RFC violations 2) Resolve issue of how to cache page fragements (or perhaps -if- we want to cache page fragements). Today, mod_cache/mod_mem_cache will cache #include 'virtual' requests (but not #include 'file' requests). This was accomplished by making CACHE_IN a CONTENT_SET-1 filter to force it to run before the SUBREQ_CORE filter. But now responses cannot be cached that include the effects of having been run through CONTENT_SET filters (mod_deflate, mod_expires, etc). We could rerun all the CONTENT_SET filters on the cached response, but this will not work in all cases. For example, mod_expires relies on installing the EXPIRATION filter during fixups. Contents served out of mod_cache (out of the quick_handler) bypass -all- the request line server hooks (Ryan really hated this. It is great for performance, but bad because of the complications listed above). jerenkrantz: There are a slew of RFC compliance bugs filed in Bugzilla for mod_cache (see 'RFC 2616 violations' below). I think fixing them is a pre-requisite before it isn't experimental. * httpd-std.conf and friends a) httpd-std.conf should be tailored by install (from src or binbuild) even if user has existing httpd.conf +1: trawick, slive, gregames, ianh, Ken, wrowe, jwoolley, jim, nd, erikabele wrowe - prefer httpd.default.conf to avoid ambiguity with cvs b) tailored httpd-std.conf should be copied by install to sysconfdir/examples -0: striker c) tailored httpd-std.conf should be installed to sysconfdir/examples or manualdir/exampleconf/ +1: slive, trawick, Ken, nd (prefer the latter), erikabele d) Installing a set of default config files when upgrading a server doesn't make ANY sense at all. +1: ianh - medium/big sites don't use 'standard config' anyway, as it usually needs major customizations -1: Ken, wrowe, jwoolley, jim, nd, erikabele wrowe - diff is wonderful when comparing old/new default configs, even for customized sites that ianh mentions jim - ... assuming that the default configs have been updated with the required inline docs to explain the changes * If the parent process dies, should the remaining child processes "gracefully" self-terminate. Or maybe we should make it a runtime option, or have a concept of 2 parent processes (one being a "hot spare"). See: Message-ID: <[EMAIL PROTECTED]> Self-destruct: Ken, Martin, Lars Not self-destruct: BrianP, Ian, Cliff, BillS Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd /* The below was a concept on *how* to handle the problem */ Have 2 parents: +1: jim -1: Justin, wrowe, rederpj, nd +0: Lars, Martin (while standing by, could it do something useful?) * Make the worker MPM the default MPM for threaded Unix boxes. +1: Justin, Ian, Cliff, BillS, striker, wrowe, nd +0:
[STATUS] (httpd-2.0) Wed Aug 4 23:45:11 EDT 2004
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2004/08/04 23:19:59 $] Release: 2.0.51 : in development 2.0.50 : released June 30, 2004 as GA. 2.0.49 : released March 19, 2004 as GA. 2.0.48 : released October 29, 2003 as GA. 2.0.47 : released July 09, 2003 as GA. 2.0.46 : released May 28, 2003 as GA. 2.0.45 : released April 1, 2003 as GA. 2.0.44 : released January 20, 2003 as GA. 2.0.43 : released October 3, 2002 as GA. 2.0.42 : released September 24, 2002 as GA. 2.0.41 : rolled September 16, 2002. not released. 2.0.40 : released August 9, 2002 as GA. 2.0.39 : released June 17, 2002 as GA. 2.0.38 : rolled June 16, 2002. not released. 2.0.37 : rolled June 11, 2002. not released. 2.0.36 : released May 6, 2002 as GA. 2.0.35 : released April 5, 2002 as GA. 2.0.34 : tagged March 26, 2002. 2.0.33 : tagged March 6, 2002. not released. 2.0.32 : released Feburary 16, 2002 as beta. 2.0.31 : rolled Feburary 1, 2002. not released. 2.0.30 : tagged January 8, 2002. not rolled. 2.0.29 : tagged November 27, 2001. not rolled. 2.0.28 : released November 13, 2001 as beta. 2.0.27 : rolled November 6, 2001 2.0.26 : tagged October 16, 2001. not rolled. 2.0.25 : rolled August 29, 2001 2.0.24 : rolled August 18, 2001 2.0.23 : rolled August 9, 2001 2.0.22 : rolled July 29, 2001 2.0.21 : rolled July 20, 2001 2.0.20 : rolled July 8, 2001 2.0.19 : rolled June 27, 2001 2.0.18 : rolled May 18, 2001 2.0.17 : rolled April 17, 2001 2.0.16 : rolled April 4, 2001 2.0.15 : rolled March 21, 2001 2.0.14 : rolled March 7, 2001 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 Please consult the following STATUS files for information on related projects: * srclib/apr/STATUS * srclib/apr-util/STATUS * docs/STATUS Contributors looking for a mission: * Just do an egrep on "TODO" or "XXX" in the source. * Review the "PatchAvailable" bugs in the bug database. Append a comment saying "Reviewed and tested". * Open bugs in the bug database. RELEASE SHOWSTOPPERS: PATCHES TO BACKPORT FROM 2.1 [ please place file names and revisions from HEAD here, so it is easy to identify exactly what the proposed changes are! ] *) Proposal: Several folks want to aggressively backport changes from mod_cache, mod_mem_cache and mod_file_cache from Apache 2.1 back into the 2.0 tree. Proposal is this: Lets drop the '3 vote' backport rule for mod_cache, mod_mem_cache and mod_file cache (for xx days?). This is a very tightly scoped easing of a rule that has served us well and we can even put an expiration date on it if we like. I intentionally did not include all exerimental modules out of respect for folks working on ldap. stoddard: +1 jwoolley: +0.5 (if we're going to backport, I don't mind us doing so aggressively since these are experimental. but i'm also of the opinion that these should not be backported at all, but rather be the 'key feature' motivating a 2.2 release.) jerenkrantz: +0.5. What Cliff said. Plus, the changes aren't just scoped to mod_cache - there's a number of other fixes elsewhere (APR has some fixes too). So, 2.2 bundled with APR 1.0 (or some variant of that) will be the first release to work 'correctly.' trawick: uhh, within the scope of the httpd developers' normal oversight over 2.0 releases (ability to review code going into a 2.0 release, preserving or enhancing maintainability, preserving binary compatibility with prior 2.0 releases, etc.), people ought to be able to fix whatever ails them in 2.0; 2.2 be damned if nobody would want to use it but for some fixes that are artificially kept out of 2.0; and any 2.0/2.2 issues are not valid reasons for keeping APR 1+ fixes/ enhancements out of APR 0.9 *) Remove LDAP toolkit specific code from util_ldap and mod_auth_ldap. modules/experimental/mod_auth_ldap.c: 1.28 modules/experimental/util_ldap.c: 1.36 +1: minfrin (this requires the apr-util LDAP overhaul to be ported to apr-util v0.9 first) -0: jerenkrantz jerenkrantz: I don't think we can change the AP
[STATUS] (apache-1.3) Wed Aug 4 23:45:06 EDT 2004
APACHE 1.3 STATUS: -*-text-*- Last modified at [$Date: 2004/05/20 15:16:42 $] Release: 1.3.32-dev: In development 1.3.31: Tagged May 7, 2004. Announced May 11, 2004. 1.3.30: Tagged April 9, 2004. Not released. 1.3.29: Tagged October 24, 2003. Announced Oct 29, 2003. 1.3.28: Tagged July 16, 2003. Announced ?? 1.3.27: Tagged September 30, 2002. Announced Oct 3, 2002. 1.3.26: Tagged June 18, 2002. 1.3.25: Tagged June 17, 2002. Not released. 1.3.24: Tagged Mar 21, 2002. Announced Mar 22, 2002. 1.3.23: Tagged Jan 21, 2002. 1.3.22: Tagged Oct 8, 2001. Announced Oct 12, 2001. 1.3.21: Not released. (Pulled for htdocs/manual config mismatch. t/r Oct 5, 2001) 1.3.20: Tagged and rolled May 15, 2001. Announced May 21, 2001. 1.3.19: Tagged and rolled Feb 26, 2001. Announced Mar 01, 2001. 1.3.18: Tagged and rolled Not released. (Pulled because of an incorrect unescaping fix. t/r Feb 19, 2001) 1.3.17: Tagged and rolled Jan 26, 2001. Announced Jan 29, 2001. 1.3.16: Not released. (Pulled because of vhosting bug. t/r Jan 20, 2001) 1.3.15: Not released. (Pulled due to CVS dumping core during the tagging when it reached src/os/win32/) 1.3.14: Tagged and Rolled Oct 10, 2000. Released/announced on the 13th. 1.3.13: Not released. (Pulled in the "first minutes" due to a Netware build bug) 1.3.12: Tagged and rolled Feb. 23, 2000. Released/announced on the 25th. 1.3.11: Tagged and rolled Jan. 19, 2000. Released/announced on the 21st. 1.3.10: Not released. (Pulled at "last minute" due to a build bug in the MPE port) 1.3.9: Tagged and rolled on Aug. 16, 1999. Released and announced on 19th. 1.3.8: Not released. 1.3.7: Not released. 1.3.6: Tagged and rolled on Mar. 22, 1999. Released and announced on 24th. 1.3.5: Not released. 1.3.4: Tagged and rolled on Jan. 9, 1999. Released on 11th, announced on 12th. 1.3.3: Tagged and rolled on Oct. 7, 1998. Released on 9th, announced on 10th. 1.3.2: Tagged and rolled on Sep. 21, 1998. Announced and released on 23rd. 1.3.1: Tagged and rolled on July 19, 1998. Announced and released. 1.3.0: Tagged and rolled on June 1, 1998. Announced and released on the 6th. 2.0 : Available for general use, see httpd-2.0 repository RELEASE SHOWSTOPPERS: RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * PR: 27023 Cookie could not delivered if the cookie made before proxy module. * isn't ap_die() broken with recognizing recursive errors Message-Id: <[EMAIL PROTECTED]> +1: jeff, jim * Current vote on 3 PRs for inclusion: Bugz #17877 (passing chunked encoding thru proxy) (still checking if RFC compliant... vote is on the correctness of the patch code only). +1: jim, chuck, minfrin Bugz #9181 (Unable to set headers on non-2XX responses) +1: Martin, Jim Gnats #10246 (Add ProxyConnAllow directive) +0: Martin (or rather -.5, see dev@ Message <[EMAIL PROTECTED]>) * htpasswd.c and htdigest.c use tmpnam()... consider using mkstemp() when available. Message-ID: <[EMAIL PROTECTED]> Status: * Dean's "unescaping hell" (unescaping the various URI components at the right time and place, esp. unescaping the host name). Message-ID: <[EMAIL PROTECTED]> Status: * Martin observed a core dump because a ipaddr_chain struct contains a NULL-"server" pointer when being dereferenced by invoking "httpd -S". Message-ID: <[EMAIL PROTECTED]> Status: Workaround enabled. Clean solution can come after 1.3.19 * long pathnames with many components and no AllowOverride None Workaround is to define with AllowOverride None, which is something all sites should do in any case. Status: Marc was looking at it. (Will asks 'wasn't this patched?') * Ronald Tschalär's patch to mod_proxy to allow other modules to set headers too (needed by mod_auth_digest) Message-ID: <[EMAIL PROTECTED]> Status: Available Patches (Most likely, will be ported to 2.0 as appropriate): * A rewrite of ap_unparse_uri_components() by Jeffrey W. Baker <[EMAIL PROTECTED]> to more fully close some segfault potential. Message-ID: <[EMAIL PROTECTED]> Status: Jim +1 (for 1.3.19), Martin +0 * Andrew Ford's patch (1999/12/05) to add absolute times to mod_expires Message-ID: <[EMAIL PROTECTED]> Status: Martin +1, Jim +1, Ken +1 (on concept) * Raymond S Brand's path to mod_autoindex to fix the header/readme include processing so the envariables are correct for the included documents. (Actually, there are two variants in the patch message, for two different ways of doing it.) Mes
Re: cvs commit: httpd-2.0 STATUS
jerenkrantz2004/08/04 12:57:30 > --- STATUS4 Aug 2004 19:31:58 - 1.751.2.967 > +++ STATUS4 Aug 2004 19:57:29 - 1.751.2.968 > @@ -94,15 +94,19 @@ >modules/experimental/util_ldap.c: 1.36 > +1: minfrin (this requires the apr-util LDAP overhaul to be ported to > apr-util v0.9 first) > + -0: jerenkrantz > + jerenkrantz: I don't think we can change the APR 0.9 interfaces. > +They are supposed to be set in stone. You cannot change the APR 0.9 interfaces. You can add new API calls, but not break binary compatibility with existing functions. That means you cannot rescope public -> private entities, cannot make transparent structures into opaque ones, and cannot change args or the return values of functions. E.g. if you need extra args to apr_foo_create(), make a new 0.9-specific function, apr_foo_create_ex(), that is folded as the real apr_foo_create() in 1.0. Bill
Re: [PATCH] mod_disk cached fixed
--On Wednesday, August 4, 2004 5:18 PM -0400 Joshua Slive <[EMAIL PROTECTED]> wrote: But it couldn't be as expensive as caching a variant for every User-Agent that accesses your site. What is probably needed is CacheVaryOn env-variable which would override the vary-matching decision to vary only on the content of env-variable (which could be just on/off in this case), but not touch the actual Vary: header, since down-stream caches wouldn't have the extra logic needed determine if they needed to vary. Disk space is cheap. ;-) I think the vary header would still be preserved in the cached copy, so I'm not sure how down-stream caches would be affected. -- justin
Re: [PATCH] mod_disk cached fixed
> Brian Akins wrote... > > Serving cached content: > > - lookup uri in cache (via md5?). > - check varies - a list of headers to vary on > - caculate new key (md5) based on uri and clients value of these headers > - lookup new uri in cache > - continue as normal Don't forget that you can't just 'MD5' a header from one response and compare it to an 'MD5' value for same header field from another response. A "Vary:" check does not mean 'has to be exactly the same as the other one'. It just has to be 'semantically' different. You can have a header value that is formatted differently from another and it is still, essentially, the SAME as another and does NOT VARY. That includes different amounts of whitespace and a different 'ordering' of the 'values'. As long as the 'values' are the SAME with regards to another header, then the header fields do NOT VARY. The only way to do it right is to be able to parse each and every header (correctly) according o BNC and and compare them that way. Syntax or whitespace differences don't automatically mean a header 'Varies' at all. > The thing that sucks is if you vary on User-Agent. You wind up with a > ton of entries per uri. Yep. That's how 'Muli-Variants' works. There might be very good reasons why every 'Varying' User-Agent needs a different 'Variant' of the same response. > I cheated in another modules by "varying" on an > environmental variable. Kind of like this: > > BrowserMatch ".*MSIE [1-3]|MSIE [1-5].*Mac.*|^Mozilla/[1-4].*Nav" no-gzip > > and just "vary" on no-gzip (1 or 0), but this may be hard to do just > using headers... It's not hard to do at all... question would be whether it's ever the 'right' thing to do. The actual compressed content for different 'User-Agents' might actually 'Vary:' as well so no one single compressed version of a response should be used to satisfy all non-no-gzip requests if there is actually a 'Vary: User-Agent' rule involved. It's pretty hard to 'cheat' on 'Vary:' That's why it remains one of the least-supported features of HTTP. It's kind of an 'all or nothing' deal whereby if you can't do it ALL correctly... then might as well do what most products do and treat ANY 'Vary:' header as if it was 'Vary: *' ( Vary: STAR ) and don't even bother trying to cache it. Kevin Kiley
Re: [PATCH] mod_disk cached fixed
On Wed, 4 Aug 2004, Justin Erenkrantz wrote: --On Wednesday, August 4, 2004 4:52 PM -0400 Brian Akins <[EMAIL PROTECTED]> wrote: The thing that sucks is if you vary on User-Agent. You wind up with a ton of entries per uri. I cheated in another modules by "varying" on an environmental variable. Kind of like this: BrowserMatch ".*MSIE [1-3]|MSIE [1-5].*Mac.*|^Mozilla/[1-4].*Nav" no-gzip and just "vary" on no-gzip (1 or 0), but this may be hard to do just using headers... Note that BrowserMatch with regexp's is ridiculously expensive. Minimizing the need for that would be goodness, I think. -- justin But it couldn't be as expensive as caching a variant for every User-Agent that accesses your site. What is probably needed is CacheVaryOn env-variable which would override the vary-matching decision to vary only on the content of env-variable (which could be just on/off in this case), but not touch the actual Vary: header, since down-stream caches wouldn't have the extra logic needed determine if they needed to vary. Joshua.
[PATCH] add ap_send_http_header back to Apache2
These's been a recent discussion over on the modperl list
(reference: http://marc.theaimsgroup.com/?t=10912298461&r=1&w=2)
with regards to C-L and HEAD requests. Dynamic handlers that know the
length of the content, but do not want to generate the content must send
something (anything) down the filter chain before returned (before EOS),
otherwise the content-length filter strips ends up stripping the C-L header.
Since the body is discarded for HEAD requests, sending anything works
(because then the content-length filter steps out of the way).
The cleanest solution seems to be to send a flush bucket to trigger
the sending of headers.
Since this seems to me to be something that lots of dynamic handlers might
use, I'd like to ask that ap_send_http_header() be re-added to Apache2.
It's implementation currently is simply to send a flush bucket down the
filter chain.
Even though HTTP headers are sent when needed, there are occasions when
dynamic handlers want to say "send headers now". ap_send_http_header()
should provide that for them. This is instead of relying on the current
behavior of a flush bucket, or can this behavior be relied upon and can
it be documented as such? Thanks!
Cheers,
Glenn
diff -ruN httpd-2.0.50/include/ap_compat.h httpd-2.0.50-new/include/ap_compat.h
--- httpd-2.0.50/include/ap_compat.h2004-02-09 15:54:33.0 -0500
+++ httpd-2.0.50-new/include/ap_compat.h2004-08-04 15:22:08.657596200 -0400
@@ -22,6 +22,5 @@
/* redefine 1.3.x symbols to the new symbol names */
#define MODULE_VAR_EXPORTAP_MODULE_DECLARE_DATA
-#define ap_send_http_header(r) ;
#endif /* AP_COMPAT_H */
diff -ruN httpd-2.0.50/include/http_protocol.h httpd-2.0.50-new/include/http_protocol.h
--- httpd-2.0.50/include/http_protocol.h2004-06-11 16:46:41.0 -0400
+++ httpd-2.0.50-new/include/http_protocol.h2004-08-04 15:26:59.078445520 -0400
@@ -73,6 +73,12 @@
/* Finish up stuff after a request */
/**
+ * Triggers sending of response headers, if not already sent to client
+ * @param r The current request
+ */
+AP_DECLARE(apr_status_t) ap_send_http_header(request_rec *r);
+
+/**
* Called at completion of sending the response. It sends the terminating
* protocol information.
* @param r The current request
diff -ruN httpd-2.0.50/modules/http/http_protocol.c
httpd-2.0.50-new/modules/http/http_protocol.c
--- httpd-2.0.50/modules/http/http_protocol.c 2004-02-09 15:53:18.0 -0500
+++ httpd-2.0.50-new/modules/http/http_protocol.c 2004-08-04 15:44:59.746159056
-0400
@@ -1275,6 +1275,15 @@
basic_http_header(r, bb, protocol);
}
+AP_DECLARE(apr_status_t) ap_send_http_header(request_rec * const r)
+{
+/* (similar to ap_rflush() but returns (apr_status_t) instead of (int)) */
+apr_bucket_alloc_t * const bucket_alloc = r->connection->bucket_alloc;
+apr_bucket_brigade * const bb = apr_brigade_create(r->pool, bucket_alloc);
+APR_BRIGADE_INSERT_HEAD(bb, apr_bucket_flush_create(bucket_alloc));
+return ap_pass_brigade(r->output_filters, bb);
+}
+
/* Navigator versions 2.x, 3.x and 4.0 betas up to and including 4.0b2
* have a header parsing bug. If the terminating \r\n occur starting
* at offset 256, 257 or 258 of output then it will not properly parse
Re: [PATCH] mod_disk cached fixed
--On Wednesday, August 4, 2004 4:52 PM -0400 Brian Akins <[EMAIL PROTECTED]> wrote: Possible scenerio: Serving cached content: - lookup uri in cache (via md5?). - check varies - a list of headers to vary on - caculate new key (md5) based on uri and clients value of these headers - lookup new uri in cache - continue as normal Caching an object: -see if object has been cached before by looking up uri in cache -do the Vary's match? -no, discard old entry(?) and create new uri entry -yes, generate new key based on client values -continue as normal I wouldn't discard the old entry, but store it as a variant to also cache. But, yes, a two-level scheme like this may make sense. This allows us to cache the gzipped and non-gzipped versions - which is what we'd want. The thing that sucks is if you vary on User-Agent. You wind up with a ton of entries per uri. I cheated in another modules by "varying" on an environmental variable. Kind of like this: BrowserMatch ".*MSIE [1-3]|MSIE [1-5].*Mac.*|^Mozilla/[1-4].*Nav" no-gzip and just "vary" on no-gzip (1 or 0), but this may be hard to do just using headers... Note that BrowserMatch with regexp's is ridiculously expensive. Minimizing the need for that would be goodness, I think. -- justin
Re: [PATCH] mod_disk cached fixed
Bill Stoddard wrote: This is the area in which mod_cache is most broken. It does not handle vary at all, thus the content needs to be stored before it is touched by any filters. But that doesn't work either because some filters will not properly run when serving content out of a quick_handler (ie, they might rely on some special something happening in the fixups hook for instance). Can't recall any exact scenarios right off the top of my busy brain but I know they exist. Would be real good to get this fixed in 2.2 So, basically, we would need to parse Vary headers and, possibly, store mulitple versions of the same uri. The vary header should just be Header names. Possible scenerio: Serving cached content: - lookup uri in cache (via md5?). - check varies - a list of headers to vary on - caculate new key (md5) based on uri and clients value of these headers - lookup new uri in cache - continue as normal Caching an object: -see if object has been cached before by looking up uri in cache -do the Vary's match? -no, discard old entry(?) and create new uri entry -yes, generate new key based on client values -continue as normal Also, if there are no Vary's on an object, there is no second key/entry. Sound reasonable? The thing that sucks is if you vary on User-Agent. You wind up with a ton of entries per uri. I cheated in another modules by "varying" on an environmental variable. Kind of like this: BrowserMatch ".*MSIE [1-3]|MSIE [1-5].*Mac.*|^Mozilla/[1-4].*Nav" no-gzip and just "vary" on no-gzip (1 or 0), but this may be hard to do just using headers... -- Brian Akins Senior Systems Engineer CNN Internet Technologies
mod_cache filter priorities was Re: [PATCH] mod_disk cached fixed
--On Wednesday, August 4, 2004 4:26 PM -0400 Brian Akins <[EMAIL PROTECTED]> wrote: Notice the plus in the second. I thought about that, too. If you place it with the +1, then you'd be after mod_deflate. I'm not yet fully sure what the implication of that would be. Moving the filters around may have some benefits. Ideally, we should come up with different strategies for moving the filter around... The only thing I know for sure is that CACHE_SAVE and CACHE_OUT need to be aligned at the same level. I guess you could have multiple variants: one if the client supports caching, the other if it doesn't. I'd have to start looking at our Vary code in depth though. -- justin
Re: cvs commit: httpd-2.0 STATUS
On 4 Aug 2004 19:57:30 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > jerenkrantz2004/08/04 12:57:30 > > Modified:.Tag: APACHE_2_0_BRANCH STATUS > Log: > Hey, look, I can cast votes! no way, what happened to the mysterious authentication which allowed only a small number of people to ever review/cast votes ;) > While it seems like no one else cares, my proposed backport of mod_ssl config > logic is stalling. We *still* can't build mod_ssl out of the box on RHEL... I'll have a look...
Re: [PATCH] mod_disk cached fixed
Brian Akins wrote:
Should this:
cache_in_filter_handle =
ap_register_output_filter("CACHE_IN",
cache_in_filter,
NULL,
AP_FTYPE_CONTENT_SET-1);
Actually be this:
cache_in_filter_handle =
ap_register_output_filter("CACHE_IN",
cache_in_filter,
NULL,
AP_FTYPE_CONTENT_SET+1);
Notice the plus in the second.
This is the area in which mod_cache is most broken. It does not handle vary at all, thus the content needs to
be stored before it is touched by any filters. But that doesn't work either because some filters will not
properly run when serving content out of a quick_handler (ie, they might rely on some special something
happening in the fixups hook for instance). Can't recall any exact scenarios right off the top of my busy
brain but I know they exist. Would be real good to get this fixed in 2.2
Bill
Re: [PATCH] mod_disk cached fixed
Should this:
cache_in_filter_handle =
ap_register_output_filter("CACHE_IN",
cache_in_filter,
NULL,
AP_FTYPE_CONTENT_SET-1);
Actually be this:
cache_in_filter_handle =
ap_register_output_filter("CACHE_IN",
cache_in_filter,
NULL,
AP_FTYPE_CONTENT_SET+1);
Notice the plus in the second.
--
Brian Akins
Senior Systems Engineer
CNN Internet Technologies
Re: [PATCH] mod_cache: Use provider API
--On Wednesday, August 4, 2004 12:39 PM -0700 Justin Erenkrantz
<[EMAIL PROTECTED]> wrote:
This patch removes the mod_cache dependencies upon the odd vtable and hooks
and standardizes upon the ap_provider_* API. mod_auth uses this provider
interface now as has mod_dav.
-- justin
Index: modules/experimental/cache_storage.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/experimental/cache_storage.c,v
retrieving revision 1.35
diff -u -r1.35 cache_storage.c
--- modules/experimental/cache_storage.c3 Aug 2004 08:20:21 - 1.35
+++ modules/experimental/cache_storage.c4 Aug 2004 05:01:08 -
@@ -17,12 +17,6 @@
#include "mod_cache.h"
-APR_HOOK_STRUCT(
- APR_HOOK_LINK(remove_url)
- APR_HOOK_LINK(create_entity)
- APR_HOOK_LINK(open_entity)
-)
-
extern APR_OPTIONAL_FN_TYPE(ap_cache_generate_key) *cache_generate_key;
extern module AP_MODULE_DECLARE_DATA cache_module;
@@ -33,22 +27,25 @@
* delete all URL entities from the cache
*
*/
-int cache_remove_url(request_rec *r, const char *types, char *url)
+int cache_remove_url(request_rec *r, char *url)
{
-const char *next = types;
-const char *type;
+cache_provider_list *list;
apr_status_t rv;
char *key;
+cache_request_rec *cache = (cache_request_rec *)
+ ap_get_module_config(r->request_config,
&cache_module);
rv = cache_generate_key(r,r->pool,&key);
if (rv != APR_SUCCESS) {
return rv;
}
+list = cache->providers;
+
/* for each specified cache type, delete the URL */
-while(next) {
-type = ap_cache_tokstr(r->pool, next, &next);
-cache_run_remove_url(type, key);
+while(list) {
+list->provider->remove_url(key);
+list = list->next;
}
return OK;
}
@@ -65,11 +62,10 @@
* decide whether or not it wants to cache this particular entity.
* If the size is unknown, a size of -1 should be set.
*/
-int cache_create_entity(request_rec *r, const char *types, char *url,
apr_off_t size)
+int cache_create_entity(request_rec *r, char *url, apr_off_t size)
{
+cache_provider_list *list;
cache_handle_t *h = apr_pcalloc(r->pool, sizeof(cache_handle_t));
-const char *next = types;
-const char *type;
char *key;
apr_status_t rv;
cache_request_rec *cache = (cache_request_rec *)
@@ -79,15 +75,19 @@
if (rv != APR_SUCCESS) {
return rv;
}
+
+list = cache->providers;
/* for each specified cache type, delete the URL */
-while (next) {
-type = ap_cache_tokstr(r->pool, next, &next);
-switch (rv = cache_run_create_entity(h, r, type, key, size)) {
+while (list) {
+switch (rv = list->provider->create_entity(h, r, key, size)) {
case OK: {
cache->handle = h;
+cache->provider = list->provider;
+cache->provider_name = list->provider_name;
return OK;
}
case DECLINED: {
+list = list->next;
continue;
}
default: {
@@ -99,19 +99,6 @@
}
/*
- * remove a specific URL entity from the cache
- *
- * The specific entity referenced by the cache_handle is removed
- * from the cache, and the cache_handle is closed.
- */
-/* XXX Don't think we need to pass in request_rec or types ... */
-int cache_remove_entity(request_rec *r, const char *types, cache_handle_t *h)
-{
-h->remove_entity(h);
-return 1;
-}
-
-/*
* select a specific URL entity in the cache
*
* It is possible to store more than one entity per URL. Content
@@ -122,10 +109,9 @@
* This function returns OK if successful, DECLINED if no
* cached entity fits the bill.
*/
-int cache_select_url(request_rec *r, const char *types, char *url)
+int cache_select_url(request_rec *r, char *url)
{
-const char *next = types;
-const char *type;
+cache_provider_list *list;
apr_status_t rv;
cache_handle_t *h;
char *key;
@@ -139,17 +125,20 @@
/* go through the cache types till we get a match */
h = cache->handle = apr_palloc(r->pool, sizeof(cache_handle_t));
-while (next) {
-type = ap_cache_tokstr(r->pool, next, &next);
-switch ((rv = cache_run_open_entity(h, r, type, key))) {
+list = cache->providers;
+
+while (list) {
+switch ((rv = list->provider->open_entity(h, r, key))) {
case OK: {
char *vary = NULL;
const char *varyhdr = NULL;
-if (cache_recall_entity_headers(h, r) != APR_SUCCESS) {
+if (list->provider->recall_headers(h, r) != APR_SUCCESS) {
/* TODO: Handle this error */
return DECLINED;
}
+r->filename = apr_pstrdup(r->pool, h->cache_obj->info.filename);
+
/*
* Check Content-Negotiation - Vary
*
@@ -205,10 +194,13 @@
return DECLINED;
}
}
+cache->provider = list->pr
[PATCH] mod_cache: Use provider API
This patch removes the mod_cache dependencies upon the odd vtable and hooks and standardizes upon the ap_provider_* API. mod_auth uses this provider interface now as has mod_dav. Besides removing a bunch of code, this has a number of beneficial side-effects: - All operations related to a cache are in *one* location/structure (yay!) - Removal of some cache wrappers that shouldn't have been there. - The remaining cache wrappers don't have to lookup/parse the 'type' string every time. Instead, it can just walk the pre-built provider list. - If a cache handler is invoked, instead of doing strcmp's to ensure it was meant to be called, they can just invoke - skipping these checks. - The ordering still remains the same (first cache to have it wins). I do have some code commented out that needs to be deleted entirely, but you can get the idea of the patch from this one. FWIW, the caching directive syntax remains the same. It's just an internal reorganization. -- justin
mod_cache backports was Re: mod_dir and mod_cache
--On Tuesday, August 3, 2004 10:29 PM -0400 Bill Stoddard <[EMAIL PROTECTED]> wrote: mod_cache, mod_mem_cache and mod_disk_cache are experimental modules in 2.0, so I am going to bypass the votes and just start backporting fixes. Please review as they go in. If something breaks, we'll fix it. Mmmm K? I'll note that without the rewritten apr_file_gets() in APR 1.1 mod_disk_cache's performance will continue to suck. (And will likely still stink on Windows as that same patch needs to be applied to all other OSes too...) And, you need the ap_internal_redirect (?) patch to cache sub-reqs... I really think people are going to have to go to 2.1/2.2 to get the best caching performance - it won't be possible to shove it all back into 2.0. That's why aiming for a GA in the next few months is a brilliant idea. I finished some radical rewrites to mod_cache to have it use the provider API. It cuts down a lot of code and makes things much cleaner and simpler. But, it removes the caching hooks entirely. (Expect that patch in a few minutes.) Backporting that isn't a viable option though. It doesn't really help performance, but does help readability and extensibility of the caching code. I've also got some patches to speed up mod_negotiation significantly as well. I had to leave last night before I could fully test it and prove that it helped. (A side effect of my test scenario is that it stresses mod_negotiation a lot.) I've also been able to identify bottlenecks in mod_setenvif and mod_auth_digest. So, I have to think about how best to resolve those, but I have some ideas that I need to sort out before posting more. -- justin
Re: mod_dir and mod_cache
Jeff Trawick wrote: On Tue, 03 Aug 2004 23:47:21 -0500, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: At 09:29 PM 8/3/2004, Bill Stoddard wrote: mod_cache, mod_mem_cache and mod_disk_cache are experimental modules in 2.0, so I am going to bypass the votes and just start backporting fixes. Please review as they go in. If something breaks, we'll fix it. Mmmm K? +++1 - if folks can't understand that modules/experimental/ means "moving target, use at your own risk", they need to attend "Using Opensource 101". Perhaps somebody who wants to change the status quo will make an appropriate note in STATUS and let people vote and/or comment? Ok, I'll bite. Updating status now. Bill
Re: [PATCH] mod_disk cached fixed
Justin Erenkrantz wrote: Looks okay - I'll take a look at incorporating it to my local changes and see how it helps. The one thing I'd change is the sizeof(char) to sizeof(newline). Since it's a constant that allows '\r\n' to be sized accordingly. -- justin Ok. It may not help you much since your limited by you bandwidth. You should see lower disk usage and cpu. Can you e-mail details about your setup (apache versions and patches) and I'll try to do some tests here. -- Brian Akins Senior Systems Engineer CNN Internet Technologies
Re: mod_dir and mod_cache
On Tue, 03 Aug 2004 23:47:21 -0500, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > At 09:29 PM 8/3/2004, Bill Stoddard wrote: > > >mod_cache, mod_mem_cache and mod_disk_cache are experimental modules in 2.0, so I > >am going to bypass the votes and just start backporting fixes. Please review as > >they go in. If something breaks, we'll fix it. Mmmm K? > > +++1 - if folks can't understand that modules/experimental/ means "moving > target, use at your own risk", they need to attend "Using Opensource 101". Perhaps somebody who wants to change the status quo will make an appropriate note in STATUS and let people vote and/or comment?
Re: [PATCH] mod_disk cached fixed
--On Wednesday, August 4, 2004 8:56 AM -0400 Brian Akins <[EMAIL PROTECTED]> wrote: Sorry about this, but the last patch had a mistake in the writev Looks okay - I'll take a look at incorporating it to my local changes and see how it helps. The one thing I'd change is the sizeof(char) to sizeof(newline). Since it's a constant that allows '\r\n' to be sized accordingly. -- justin
Re: [PATCH] mod_disk cached fixed
--On Wednesday, August 4, 2004 5:26 PM +0200 Graham Leggett <[EMAIL PROTECTED]> wrote: How resilient is this to garbage data on the disk? A risk exists of somebody getting write access to the headers cache file, and then crafting a cache headers file which when read causes a takeover of the webserver. Just want to check that it's covered. It's only reading in integers not pointers. So I don't see how it'd cause a security risk. -- justin
Re: cvs commit: httpd-2.0 STATUS
Brad Nicholes wrote: Do we care about backporting the overhaul into the 2.0 tree? I don't see that it really buys us anything unless you think that it is necessary in order to get auth_ldap out of experimental. After I get the latest util-ldap fixes backported, that should get mod_auth_ldap working in 2.0. Once it actually works, I think we can then propose that it is moved out of experimental. In theory it doesn't really buy us anything no - it depends on how strongly people feel about the fooness in the LDAP code being removed from APR v0.9.4, but as to my knowledge there has never been an ASF blessed release of the 0.9 branch of APR, so in theory there would be no point. The next thing that needs to be done would be to rework mod_auth_ldap so that it complies with the rest of the 2.1 auth module structure.The util-ldap overhaul could be considered part of that work and only be available in 2.1. Thoughts? That definitely is next - as mod_auth_ldap is currently non functional in v2.1 due to it not following the authn/authz convention. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH] mod_disk cached fixed
Graham Leggett wrote: How resilient is this to garbage data on the disk? A risk exists of somebody getting write access to the headers cache file, and then crafting a cache headers file which when read causes a takeover of the webserver. Just want to check that it's covered. That exists for the current way as well.You could do a quick check to make sure the numbers look resonable, I suppose. -- Brian Akins Senior Systems Engineer CNN Internet Technologies
Re: cvs commit: httpd-2.0 STATUS
Do we care about backporting the overhaul into the 2.0 tree? I don't see that it really buys us anything unless you think that it is necessary in order to get auth_ldap out of experimental. After I get the latest util-ldap fixes backported, that should get mod_auth_ldap working in 2.0. Once it actually works, I think we can then propose that it is moved out of experimental. The next thing that needs to be done would be to rework mod_auth_ldap so that it complies with the rest of the 2.1 auth module structure.The util-ldap overhaul could be considered part of that work and only be available in 2.1. Thoughts? Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com >>> [EMAIL PROTECTED] Tuesday, August 03, 2004 7:09:01 PM >>> minfrin 2004/08/03 18:09:01 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: Propose a backport. Revision ChangesPath No revision No revision 1.751.2.965 +7 -1 httpd-2.0/STATUS Index: STATUS === RCS file: /home/cvs/httpd-2.0/STATUS,v retrieving revision 1.751.2.964 retrieving revision 1.751.2.965 diff -u -r1.751.2.964 -r1.751.2.965 --- STATUS3 Aug 2004 19:07:03 - 1.751.2.964 +++ STATUS4 Aug 2004 01:09:00 - 1.751.2.965 @@ -73,6 +73,12 @@ [ please place file names and revisions from HEAD here, so it is easy to identify exactly what the proposed changes are! ] +*) Remove LDAP toolkit specific code from util_ldap and mod_auth_ldap. + modules/experimental/mod_auth_ldap.c: 1.28 + modules/experimental/util_ldap.c: 1.36 + +1: minfrin (this requires the apr-util LDAP overhaul to be ported to +apr-util v0.9 first) + *) Add load balancer support to the scoreboard in preparation for load balancing support in mod_proxy. include/scoreboard.h: 1.52
Re: [PATCH] mod_disk cached fixed
Brian Akins wrote: Sorry about this, but the last patch had a mistake in the writev How resilient is this to garbage data on the disk? A risk exists of somebody getting write access to the headers cache file, and then crafting a cache headers file which when read causes a takeover of the webserver. Just want to check that it's covered. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH] mod_disk_cache metadata
> Note: I haven't actually tested this in mod_cache. Very similar code > works very well elsewhere.
Re: mod_dir and mod_cache
At 09:29 PM 8/3/2004, Bill Stoddard wrote: >mod_cache, mod_mem_cache and mod_disk_cache are experimental modules in 2.0, so I am >going to bypass the votes and just start backporting fixes. Please review as they go >in. If something breaks, we'll fix it. Mmmm K? +++1 - if folks can't understand that modules/experimental/ means "moving target, use at your own risk", they need to attend "Using Opensource 101". Bill
Re: mod_dir and mod_cache
Since these modules are experimental (still), the backport procedure is (or should be) much more relaxed than with non-exp modules. Heck, I would almost say that anything added to the 2.1 tree for exp. modules should *always* be added to the 2.0 tree as well (for experimental modules). :) Bill Stoddard wrote: > > Brian Akins wrote: > > I think I missed the answer to this: > > > > Has the "feature" that prevents mod_cache from caching urls ending in / > > (as related to mod_dir) been "fixed"? If so, will this make it into 2.0? > > > yes it has been fixed. I volunteer to help with the backport. Just need to get the > votes to backport for each > patch. > > Bill > -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: logging actually transferred bytes
On Tue, 3 Aug 2004 01:23:36 +0200, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I noticed that %b directive in CustomLog *should* mean "Bytes sent, excluding > HTTP headers" but it doesn't seem to work like this. I think it just mean > Content-Length returned in HTTP-response. > > Is there a way to get accurate number of bytes actually transferred (taking > into account cancelled and partial downloads)? isn't that what mod_logio does tries to account for? see http://httpd.apache.org/docs-2.0/mod/mod_logio.html
[PATCH] mod_disk cached fixed
Sorry about this, but the last patch had a mistake in the writev
--
Brian Akins
Senior Systems Engineer
CNN Internet Technologies
--- httpd-2.0.50.old/modules/experimental/mod_disk_cache.c 2004-02-09
15:53:16.0 -0500
+++ httpd-2.0.50/modules/experimental/mod_disk_cache.c 2004-08-04 08:54:21.0
-0400
@@ -43,6 +43,14 @@
apr_off_t file_size; /* File size of the cached data file */
} disk_cache_object_t;
+typedef struct {
+apr_time_t date;
+apr_time_t expire;
+apr_time_t version;
+apr_time_t request_time;
+apr_time_t response_time;
+} disk_cache_info_t;
+
/*
* mod_disk_cache configuration
*/
@@ -177,36 +185,22 @@
apr_status_t rv;
char urlbuff[1034]; /* XXX FIXME... THIS IS A POTENTIAL SECURITY HOLE */
int urllen = sizeof(urlbuff);
-int offset=0;
char * temp;
+disk_cache_info_t disk_info;
+apr_size_t len;
-/* read the data from the cache file */
-/* format
- * date SP expire SP count CRLF
- * dates are stored as a hex representation of apr_time_t (number of
- * microseconds since 00:00:00 january 1, 1970 UTC)
- */
-rv = apr_file_gets(&urlbuff[0], urllen, fd);
+ /* read the data from the cache file */
+len = sizeof(disk_cache_info_t);
+rv = apr_file_read(fd, &disk_info, &len);
if (rv != APR_SUCCESS) {
return rv;
}
-if ((temp = strchr(&urlbuff[0], '\n')) != NULL) /* trim off new line character */
-*temp = '\0'; /* overlay it with the null terminator */
-
-if (!apr_date_checkmask(urlbuff, "
")) {
-return APR_EGENERAL;
-}
-
-info->date = ap_cache_hex2usec(urlbuff + offset);
-offset += (sizeof(info->date)*2) + 1;
-info->expire = ap_cache_hex2usec(urlbuff + offset);
-offset += (sizeof(info->expire)*2) + 1;
-dobj->version = ap_cache_hex2usec(urlbuff + offset);
-offset += (sizeof(info->expire)*2) + 1;
-info->request_time = ap_cache_hex2usec(urlbuff + offset);
-offset += (sizeof(info->expire)*2) + 1;
-info->response_time = ap_cache_hex2usec(urlbuff + offset);
+info->date = disk_info.date;
+info->expire = disk_info.expire;
+dobj->version = disk_info.version;
+info->request_time = disk_info.request_time;
+info->response_time = disk_info.response_time;
/* check that we have the same URL */
rv = apr_file_gets(&urlbuff[0], urllen, fd);
@@ -217,11 +211,8 @@
if ((temp = strchr(&urlbuff[0], '\n')) != NULL) { /* trim off new line character
*/
*temp = '\0'; /* overlay it with the null terminator */
}
-
-if (strncmp(urlbuff, "X-NAME: ", 7) != 0) {
-return APR_EGENERAL;
-}
-if (strcmp(urlbuff + 8, dobj->name) != 0) {
+
+if (strcmp(urlbuff, dobj->name) != 0) {
return APR_EGENERAL;
}
@@ -232,41 +223,37 @@
{
apr_status_t rc;
char *buf;
-apr_size_t amt;
-
-char dateHexS[sizeof(apr_time_t) * 2 + 1];
-char expireHexS[sizeof(apr_time_t) * 2 + 1];
-char verHexS[sizeof(apr_time_t) * 2 + 1];
-char requestHexS[sizeof(apr_time_t) * 2 + 1];
-char responseHexS[sizeof(apr_time_t) * 2 + 1];
-cache_info *info = &(h->cache_obj->info);
disk_cache_object_t *dobj = (disk_cache_object_t *) h->cache_obj->vobj;
-
+disk_cache_info_t disk_info;
+const char *newline = "\n";
+struct iovec iov[3];
+
if (!r->headers_out) {
/* XXX log message */
return 0;
}
-ap_cache_usec2hex(info->date, dateHexS);
-ap_cache_usec2hex(info->expire, expireHexS);
-ap_cache_usec2hex(dobj->version++, verHexS);
-ap_cache_usec2hex(info->request_time, requestHexS);
-ap_cache_usec2hex(info->response_time, responseHexS);
-buf = apr_pstrcat(r->pool, dateHexS, " ", expireHexS, " ", verHexS, " ",
requestHexS, " ", responseHexS, "\n", NULL);
-amt = strlen(buf);
-rc = apr_file_write(fd, buf, &amt);
-if (rc != APR_SUCCESS) {
-/* XXX log message */
+disk_info.date = info->date;
+disk_info.expire = info->expire;
+disk_info.version = dobj->version++;
+disk_info.request_time = info->request_time;
+disk_info.response_time = info->response_time;
+
+
+iov[0].iov_base = &disk_info;
+iov[0].iov_len = sizeof(disk_cache_info_t);
+iov[1].iov_base = dobj->name;
+iov[1].iov_len = strlen(dobj->name);
+iov[2].iov_base = newline;
+iov[2].iov_len = sizeof(char); /*you never know*/
+
+if ((rc =
+ apr_file_writev(fd, (const struct iovec *) &iov, 3,
+ &len)) != APR_SUCCESS) {
return 0;
+
}
-buf = apr_pstrcat(r->pool, "X-NAME: ", dobj->name, "\n", NULL);
-amt = strlen(buf);
-rc = apr_file_write(fd, buf, &amt);
-if (rc != APR_SUCCESS) {
-/* XXX log message */
-return 0;
-}
return 1;
}
[PATCH] mod_disk_cache metadata
This speeds up writing and reading the "metadata" by using a struct
rather that all the calls to ap_cache_usec2hex
Note: I haven't actually tested this in mod_cache. Very similar code
works very well elsewhere.
--
Brian Akins
Senior Systems Engineer
CNN Internet Technologies
--- httpd-2.0.50.old/modules/experimental/mod_disk_cache.c 2004-02-09
15:53:16.0 -0500
+++ httpd-2.0.50/modules/experimental/mod_disk_cache.c 2004-08-04 08:47:28.0
-0400
@@ -43,6 +43,14 @@
apr_off_t file_size; /* File size of the cached data file */
} disk_cache_object_t;
+typedef struct {
+apr_time_t date;
+apr_time_t expire;
+apr_time_t version;
+apr_time_t request_time;
+apr_time_t response_time;
+} disk_cache_info_t;
+
/*
* mod_disk_cache configuration
*/
@@ -179,34 +187,21 @@
int urllen = sizeof(urlbuff);
int offset=0;
char * temp;
+disk_cache_info_t disk_info;
+apr_size_t len;
-/* read the data from the cache file */
-/* format
- * date SP expire SP count CRLF
- * dates are stored as a hex representation of apr_time_t (number of
- * microseconds since 00:00:00 january 1, 1970 UTC)
- */
-rv = apr_file_gets(&urlbuff[0], urllen, fd);
+ /* read the data from the cache file */
+len = sizeof(disk_cache_info_t);
+rv = apr_file_read(fd, &disk_info, &len);
if (rv != APR_SUCCESS) {
return rv;
}
-if ((temp = strchr(&urlbuff[0], '\n')) != NULL) /* trim off new line character */
-*temp = '\0'; /* overlay it with the null terminator */
-
-if (!apr_date_checkmask(urlbuff, "
")) {
-return APR_EGENERAL;
-}
-
-info->date = ap_cache_hex2usec(urlbuff + offset);
-offset += (sizeof(info->date)*2) + 1;
-info->expire = ap_cache_hex2usec(urlbuff + offset);
-offset += (sizeof(info->expire)*2) + 1;
-dobj->version = ap_cache_hex2usec(urlbuff + offset);
-offset += (sizeof(info->expire)*2) + 1;
-info->request_time = ap_cache_hex2usec(urlbuff + offset);
-offset += (sizeof(info->expire)*2) + 1;
-info->response_time = ap_cache_hex2usec(urlbuff + offset);
+info->date = disk_info.date;
+info->expire = disk_info.expire;
+dobj->version = disk_info.version;
+info->request_time = disk_info.request_time;
+info->response_time = disk_info.response_time;
/* check that we have the same URL */
rv = apr_file_gets(&urlbuff[0], urllen, fd);
@@ -217,11 +212,8 @@
if ((temp = strchr(&urlbuff[0], '\n')) != NULL) { /* trim off new line character
*/
*temp = '\0'; /* overlay it with the null terminator */
}
-
-if (strncmp(urlbuff, "X-NAME: ", 7) != 0) {
-return APR_EGENERAL;
-}
-if (strcmp(urlbuff + 8, dobj->name) != 0) {
+
+if (strcmp(urlbuff, dobj->name) != 0) {
return APR_EGENERAL;
}
@@ -232,41 +224,37 @@
{
apr_status_t rc;
char *buf;
-apr_size_t amt;
-
-char dateHexS[sizeof(apr_time_t) * 2 + 1];
-char expireHexS[sizeof(apr_time_t) * 2 + 1];
-char verHexS[sizeof(apr_time_t) * 2 + 1];
-char requestHexS[sizeof(apr_time_t) * 2 + 1];
-char responseHexS[sizeof(apr_time_t) * 2 + 1];
-cache_info *info = &(h->cache_obj->info);
disk_cache_object_t *dobj = (disk_cache_object_t *) h->cache_obj->vobj;
-
+disk_cache_info_t disk_info;
+const char *newline = "\n";
+struct iovec iov[3];
+
if (!r->headers_out) {
/* XXX log message */
return 0;
}
-ap_cache_usec2hex(info->date, dateHexS);
-ap_cache_usec2hex(info->expire, expireHexS);
-ap_cache_usec2hex(dobj->version++, verHexS);
-ap_cache_usec2hex(info->request_time, requestHexS);
-ap_cache_usec2hex(info->response_time, responseHexS);
-buf = apr_pstrcat(r->pool, dateHexS, " ", expireHexS, " ", verHexS, " ",
requestHexS, " ", responseHexS, "\n", NULL);
-amt = strlen(buf);
-rc = apr_file_write(fd, buf, &amt);
-if (rc != APR_SUCCESS) {
-/* XXX log message */
+disk_info.date = info->date;
+disk_info.expire = info->expire;
+disk_info.version = dobj->version++;
+disk_info.request_time = info->request_time;
+disk_info.response_time = info->response_time;
+
+
+iov[0].iov_base = &disk_info;
+iov[0].iov_len = sizeof(disk_cache_info_t);
+iov[1].iov_base = dobj->name;
+iov[1].iov_len = strlen(dobj->name);
+iov[1].iov_base = newline;
+iov[0].iov_len = sizeof(char); /*you never know*/
+
+if ((rc =
+ apr_file_writev(fd, (const struct iovec *) &iov, 3,
+ &len)) != APR_SUCCESS) {
return 0;
+
}
-buf = apr_pstrcat(r->pool, "X-NAME: ", dobj->name, "\n", NULL);
-amt = strlen(buf);
-rc = apr_file_write(fd, buf, &amt);
-if (rc != APR_SUCCESS) {
-/* XXX log message */
-
Re: mod_dir and mod_cache
mod_cache, mod_mem_cache and mod_disk_cache are experimental modules in 2.0, so I am going to bypass the votes and just start backporting fixes. Please review as they go in. If something breaks, we'll fix it. Mmmm K? no, not okay ok if you wish for everybody to be able to use different rules for all experimental modules, please start a discussion with appropriate subject for consideration The discussion would take more time than getting the votes. I'll start nominating backports soon, so vote-on (and I'll remove the one backport I already did). BTW, in between Win2k BSODs last nite (a sign perhaps, of many things :-), I ran into a new APR function used by 2.1 mod_cache, apr_strtoff(). Someone could do much worse than to take a look at this to see if it is suitable for backporting into the APR 0.9 branch. Bill
Re: mod_dir and mod_cache
On Tue, 03 Aug 2004 22:29:01 -0400, Bill Stoddard <[EMAIL PROTECTED]> wrote: > > > Bill Stoddard wrote: > > > Brian Akins wrote: > > > >> I think I missed the answer to this: > >> > >> Has the "feature" that prevents mod_cache from caching urls ending in > >> / (as related to mod_dir) been "fixed"? If so, will this make it into > >> 2.0? > >> > > yes it has been fixed. I volunteer to help with the backport. Just need > > to get the votes to backport for each patch. > > > > Bill > > > > mod_cache, mod_mem_cache and mod_disk_cache are experimental modules in 2.0, so I am > going to bypass the votes > and just start backporting fixes. Please review as they go in. If something breaks, > we'll fix it. Mmmm K? no, not okay if you wish for everybody to be able to use different rules for all experimental modules, please start a discussion with appropriate subject for consideration
