Re: PR42829
On Fri, May 30, 2008 at 8:03 AM, Stefan Fritsch [EMAIL PROTECTED] wrote: On Friday 30 May 2008, Paul Querna wrote: https://issues.apache.org/bugzilla/attachment.cgi?id=21137 has been in Debian testing and unstable for about 6 months without problems. It is not an elegant solution but it works. Considering that is is not clear how an elegant solution would look like, including this patch might make sense. Please don't put these kind of patches into the debian apache packages, especially ones that don't exist in trunk. (Things that are committed to turnk, and just are awaiting backport, I'm less concerned about, but this patch is a behavior change at the core of the MPMs.) Bugs as grave as this one are not acceptable in Debian packages for extended periods of time. The bug report has been open for over 1 year, I have attached my patch on 2007-11-16. It is marked as critical since 2008-01-16. If you don't want such patches in the Debian package, you need to fix such bugs faster (and comment on patches in bugzilla faster). Of course I understand that this is difficult because there are never enough people to fix bugs (we have the same problem). To take it to the extreme, a fork being called 'Apache' isn't acceptable either. Please work with us here, even though it's a very low barrier for you to put patches in your package, much lower than to get it applied upstream (here). I admit that I should have followed up on the discussion in February, but I was quite busy and then forgot about it. Cheers, Sander
Re: dtrace probes for 2.2.x
On Mon, May 5, 2008 at 8:31 PM, Paul Querna [EMAIL PROTECTED] wrote: Mads Toftum wrote: Theo just announced dtrace probes for httpd: http://www.opensolaris.org/jive/thread.jspa?threadID=59306tstart=0 I wouldn't mind seeing those (or something similar) make it into trunk. +1, this would be very nice. I'd be happy to help shepherd it in. I believe we would need to get a CLA from Theo or OmniIT (don't think it would be a problem if we asked nicely :P) At the very least, they would need to submit it as a .patch to this list, saying that we can use it. Well, there you have it :) Cheers, Sander
Re: mod_serf is in trunk
On 11/13/07, Paul Querna [EMAIL PROTECTED] wrote: I've added mod_serf in r594425: http://svn.apache.org/viewvc?view=revrevision=594425 Nice! I've grown exceptionally... tired of looking at mod_proxy. mod_serf is nice and tight at 440 lines or so. A cool low number. Fits snugly with the idea of having httpd 3.0 revolving around a serf core. With just a little more work, I think it could be a production level reverse proxy. Oh yeah, and death to ProxyPass, ProxyPassMatch and all similar directives that should just go inside Location Blocks. mod_serf will put everything inside a location block like this: Location /foo SerfPass http://www.exmaple.com/ SerfPreseveHost On SerfReversePass off SerfTimeout 5 /Location So no more semi-global configurations options like mod_proxy has. Thoughts? Cool addition, definitely worth exploring further. Sander
Re: [PATCH]: mod_cache: don't store headers that will never be used
On 7/31/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Niklas Edmundsson wrote: On Mon, 30 Jul 2007, Niklas Edmundsson wrote: However, if stuff is really depending on Date/Expires being what it thinks it is (*shiver*) then I guess there won't be any other options... Here's a version with a config directive, defaults to disabled. Silly Q; a directive? Or a env var that can be scoped in interesting ways using mod_setenvif and/or mod_rewrite? Most of our proxy behavior overrides are in terms of envvars. They are much more flexible to being tuned per-browser, per-backend etc. Directive, envvar, I don't think Niklas cares much. Can we make up our mind please? Sander
Re: mod_cache: Don't update when req max-age=0?
On 5/24/07, Niklas Edmundsson [EMAIL PROTECTED] wrote: On Tue, 22 May 2007, Henrik Nordstrom wrote: tis 2007-05-22 klockan 11:40 +0200 skrev Niklas Edmundsson: -8--- Does anybody see a problem with changing mod_cache to not update the stored headers when the request has max-age=0, the body turns out not to be stale and the on-disk header hasn't expired? -8--- My understanding: It's fine in an RFC point of view for the cache to completely ignore a 304 and not update the stored entity at all. But the response to this request should be the merge of the two responses assuming the conditional was added by the cache. This is in line with my understanding, and since the response-merging is being done today the only change that would be done is to skip storing the header to disk. I think it would be wise to only skip the storing for the max-age=0 case though. Why limit it to the the max-age=0 case? Isn't it a general improvement? Sander
Serf, WAS: Re: AW: AW: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
Plüm wrote: I think the SSL problem is caused by throwing away the conn_rec entry for the backend and create a new one for each request. That does not sound right, but I admit that keeping it must be carefully examinated due to several possible issues. Two that I can see immeditately are: 1. memory pools 2. filters For me that puts the question on the table if using fake request_rec and conn_rec structures for the backend connections is really a good idea. This misuse already leads to problems in other areas. But reworking this will take much time and work and is only mid to long term. Might be easier if we have a http / https client library as part of httpd or apr-util. Something like this maybe: http://svn.webdav.org/repos/projects/serf/trunk/ It started out to become apr-serf, made a jump to the short-lived Commons, and ended up at webdav.org. There is a current effort by Justin Erenkrantz to get Serf completed, or at least complete enough to complete ra_serf, a Subversion remote access library. I expect that with a couple of months the churn is gone, and its API stable enough to use here in HTTP Server land. Sander
Re: 2.07-rc4 available for testing
+1, passes 'make test' on Ubuntu Linux 5.10. Thanks, Sander
Re: mod_proxy, another case of ignoring the filter stack?
Brian Akins wrote: Sander Striker wrote: Ok, let me tell you why I want it. I want to implement a directive called CacheErrorServeStale, which, when it hits the CACHE_SAVE filter say with a 503 Service Temporarily Unavailable, and has a cache-stale_handle, continues as if it would have received a 304 Not Modified. That's one use of the request_status hook in mod_proxy. If mod_cache registered a handler for it, it could handle all instances where the proxy fails. No, mod_cache doesn't have to know what the origin is. It can be anything from a custom handler, a cgi, etc. This list happens to include mod_proxy, but I don't think we need to handle mod_proxy any differently. Rudigers suggestion of pushing an error bucket down the filter stack seems the best solution, which I'm working on implementing. Sander
Pools bug?, WAS: Re: Event MPM: Spinning on cleanups?
Roy T. Fielding wrote:
On Dec 30, 2005, at 5:51 PM, Brian Pane wrote:
I haven't been able to find the bug yet. As a next step, I'll try using
valgrind on a build with pool debugging enabled.
On entry to allocator_free, if
(node == node-next node-index current_free_index)
is true, then the do { } while ((node = next) != NULL);
will go into an infinite loop. This is because
if (max_free_index != APR_ALLOCATOR_MAX_FREE_UNLIMITED
index current_free_index) {
node-next = freelist;
freelist = node;
}
does not update current_free_index. I don't know if that is the
problem, but it may be the symptom.
Roy
Hmm, I'll go over the pools code once more to see if there really
is an obscure edge case bug hitting us.
Sander
Re: mod_proxy, another case of ignoring the filter stack?
Ruediger Pluem wrote: On 12/29/2005 02:11 AM, Sander Striker wrote: [..cut..] First it doesn't seem to be the case that mod_proxy actually sets r-status in the case of an error (service temporarily unavailable caused by ProxyTimeout for instance). This may not matter for a handler, but... Just for my understanding: Is it really needed to set r-status in these cases? Isn't it sufficient if the handler just delivers the status code as return value in this case? Secondly in case we hit the cleanup phase (for example when we hit an error like above), mod_proxy doesn't allow filters that were set up a chance to run. I remember myself that we both worked on a similar problem with the default handler about 6 month ago: Yeah, I recalled that discussion as well and thought: hey, more of the same. http://mail-archives.apache.org/mod_mbox/httpd-dev/200505.mbox/[EMAIL PROTECTED] At least in the default handler case I faced some problems with the error page handling if the EOS was sent down the filter chain for the error case by the handler. Hrmpf. I kindof hoped we finally resolved that, but I guess not. So I am not convinced right now that doing so is a good idea. Ok, let me tell you why I want it. I want to implement a directive called CacheErrorServeStale, which, when it hits the CACHE_SAVE filter say with a 503 Service Temporarily Unavailable, and has a cache-stale_handle, continues as if it would have received a 304 Not Modified. Ofcourse, this won't work if the cache save filter is never hit. Sander
mod_proxy, another case of ignoring the filter stack?
Hi,
I'm timing out on this one, but I thought I'd throw it in here in
case someone has a bright idea on what is actually going on...
First it doesn't seem to be the case that mod_proxy actually
sets r-status in the case of an error (service temporarily
unavailable caused by ProxyTimeout for instance). This may
not matter for a handler, but...
Secondly in case we hit the cleanup phase (for example when
we hit an error like above), mod_proxy doesn't allow filters
that were set up a chance to run.
Hereby a tiny patch to fix these issues, though I'd like some
feedback whether this is the correct spot to do this in mod_proxy.
Thanks,
Sander
Index: modules/proxy/mod_proxy.c
===
--- modules/proxy/mod_proxy.c (revision 359556)
+++ modules/proxy/mod_proxy.c (working copy)
@@ -790,6 +790,18 @@
proxy_run_request_status(access_status, r);
+if (!r-eos_sent) {
+apr_bucket_brigade *bb;
+apr_bucket *e;
+
+r-status = access_status;
+
+bb = apr_brigade_create(r-pool, r-connection-bucket_alloc);
+e = apr_bucket_eos_create(bb-bucket_alloc);
+APR_BRIGADE_INSERT_TAIL(bb, e);
+ap_pass_brigade(r-output_filters, bb);
+}
+
return access_status;
}
Re: [PATCH] mod_proxy run cleanup on balancer failure
[EMAIL PROTECTED] wrote:
As I try to improve my Apache code style awareness. What is wrong with the
formatting?
http://httpd.apache.org/dev/styleguide.html
The basic objection to your patch would be that statements after
your if's; put them on the next line.
HTH,
Sander
Regards
Rüdiger
Jim Jagielski wrote:
Except for the formatting +1 :)
On Sep 29, 2005, at 12:01 PM, [EMAIL PROTECTED] wrote:
What about the following patch? I think it should address all the things
discussed.
Regards
Rüdiger
Index: mod_proxy.c
===
--- mod_proxy.c (Revision 280422)
+++ mod_proxy.c (Arbeitskopie)
@@ -679,8 +679,20 @@
char *url = uri;
/* Try to obtain the most suitable worker */
access_status = ap_proxy_pre_request(worker, balancer, r,
conf, url);
-if (access_status != OK)
-return access_status;
+if (access_status != OK) {
+/*
+ * Only return if access_status is not
HTTP_SERVICE_UNAVAILABLE
+ * This gives other modules the chance to hook into the
+ * request_status hook and decide what to do in this
situation.
+ */
+if (access_status != HTTP_SERVICE_UNAVAILABLE) return
access_status;
+/*
+ * Ensure that balancer is NULL if worker is NULL to
prevent
+ * potential problems in the post_request hook.
+ */
+if (!worker) balancer = NULL;
+goto cleanup;
+}
if (balancer balancer-max_attempts_set !max_attempts)
max_attempts = balancer-max_attempts;
/* firstly, try a proxy, unless a NoProxy directive is
active */
Re: Apache 2.1/2.2/2.3...
Jim Jagielski wrote: William A. Rowe, Jr. wrote: Jim Jagielski wrote: Could someone explain to me what the current thinking is about the httpd SVN trunk? Is it 2.3.0? 2.1.x? Where does 2.2 fit in all this? So patches made to HEAD/trunk need to be backported to 2.2, and 2.1 and then 2.0 ??? Does anyone else think this is more complex than it needs to be? :) I thought so... but the list disagreed and nobody else had any issues with the branch. So trunk is 2.3-dev. My confusion deals with how patches are synced... Patches I applied to TRUNK made it to the 2.2 branch after it was branched, it appears. I fear that just as viable patches are being missed from being folded into 2.0, it will be even worse between TRUNK and 2.2, simply because they track SO close now. Or, conversely, stuff folded into the 2.2 branch may not end up in trunk. The latter should never happen. Develop on trunk, merge back to stable: 2.2 branch, or 2.2 branch and 2.0 branch. At least, that's what I envisioned after all the discussion on how to move on with the branch/versioning scheme. Sander
Re: svn commit: r220307 - in /httpd/httpd/trunk/modules: metadata/mod_setenvif.c ssl/mod_ssl.c ssl/mod_ssl.h ssl/ssl_expr_eval.c
Joe Orton wrote: On Fri, Jul 22, 2005 at 12:11:56PM -, Martin Kraemer wrote: Author: martin Date: Fri Jul 22 05:11:55 2005 New Revision: 220307 URL: http://svn.apache.org/viewcvs?rev=220307view=rev Log: Allow extraction of the values of SSL certificate extensions into environment variables, so that their value can be used by any module that is aware of environment variables, as in: So what is the point in posting patches for review if you don't actually wait for anyone to review them before committing? That would be my fault. We're here at ApacheCon and when Martin said he posted to the list first I asked him why he didn't commit to trunk directly, since that is C-T-R. It's a reasonable smallish patch, with little impact on existing functionality; hence the nudge. Sander
[Fwd: [PATCH] 404 does not delete cached entries using mod_disk_cache]
Forwarding for Rüdiger, since he's having some problems posting. Sander Original Message Subject: [PATCH] 404 does not delete cached entries using mod_disk_cache Date: Thu, 21 Jul 2005 14:52:19 +0200 From: Plüm, Rüdiger, VIS [EMAIL PROTECTED] To: [EMAIL PROTECTED] After having a discussion with various people (Sander, Justin, Paul) at the ApacheCon I submit a new version of my 404 does not delete cached entries using mod_disk_cache: Some comments: 1. In the case that there is an Apache generated error message the content filters get removed. This problem is now solved by adding a protocol filter (CACHE_REMOVE_URL) in the quick handler each time we add the cache save filter. If the cache save filter caches the response from the backend it just removes this filter from the chain. As the request CACHE_REMOVE_URL is running on a request that might be different fromi the one where the cache entry should be flushed, the cache request rec is taken from the filter context where it has been saved during insertation. 2. I adjusted the cache provider API for remove_url as I needed to have a pool and (in case of mod_disk_cache) the file name present at remove_url. Thus the prototype for remove url does now look like the following: int (*remove_url) (cache_handle_t *h, apr_pool_t *p); Comments / thoughts? Regards Rüdiger new_404_patch_trunk.diff Description: Binary data
Re: [vote] Revoke R-T-C [was: svn commit: r219520]
William A. Rowe, Jr. wrote: At 12:51 PM 7/18/2005, Roy T. Fielding wrote: Or you could simply keep working on trunk like everyone else and let releases be made when a tarball gets three +1s. Version numbers are cheap. Telling the entire group to stop while you work on the next big patch is extremely expensive. Ok, so we are now three levels deep? /trunk C-T-R /branches/2.2.x [misnomer, we don't have a beta yet] R-T-C ? If not now, when? /branches/2.0.x R-T-C There should be natural migration to 2.2.x. 2.0.x should be considered closed for new features, that's what the development line is for. Triple commits to fix one, one-line segfault? Well, this isn't workable. I think lack of progress shows it's not workable. The lack of progress is not due to having to commit to multiple branches. Some of us, trawick, orton and myself come to mind, are still up for supporting our current users. You make it sound like everybody else is dissing our current users. This broad characterization is not exactly productive. As it is, backports aren't reviewed, or committed once they are (I even split STATUS just to call out approved-yet-not-backported patches :-). The person who proposed the backport is expected to perform the backport when it has enough votes. The person casting the 3rd vote sometimes does the backport. And there are cases when a friendly RM clears the slate when it comes to approved proposed backports. Some were working on the stable release of 2.2.x, pquerna comes firstmost to mind. It isn't just Paul who wants to see 2.2.x finally materialize. We've been trying to get 2.2.x out for quite a while. We've come very close a couple of times, and because we like consensus we've not pushed too hard. I for one don't want to sit here again next year and still discuss what needs to be fixed/refactored/whatever before 2.2.x can be released. Let's just move on. 2.2.x is already a lot better than 2.0.x; our users deserve a release. Great progress is afoot, I see that release going beta very soon, the number of issues has dropped quite significantly. [Although we have 29 PatchAvailable issues, not sure how many correspond to 2.2 commits not backported.] And others are yet working on 2.4.x. 2.3.x, leading up to 2.4.x. As of the branch you are one of the people working on that, what's the issue with that? So, I call a vote that we drop R-T-C altogether. It's pretty clear to me that those interested in current / near-future / far-future users are almost three distinct groups. It will be up to those small groups to call out and vote on changes within our individual domains. Define current, near-future, far-future. current == 1.3? near-future == 2.0? far-future == 2.x? As it stands, only trunk should be C-T-R IMO. Stability on the _stable_ branches needs to be ensured. The question is; would we rather be saturated by commits we feel need review, or exhausted waiting for commits to be approved? The latter, but again, it's a broad characterization. This means code might be committed to 2.0.x and never fixed in head, it might mean code is fixed in head and never considered for backport to our current users, but all in all, it beats the situation today. No it doesn't. trunk needs to be the branch that has the latest code, and is most complete. I'm not suggesting that the 2.0.x users would entertain a break to ABI compatibility. But I'm suggesting that parallel development doesn't work when most folks are focused on tangential development. Sander
MMN, versioning, WAS: Re: svn commit: r219372 - in /httpd/httpd/trunk ...
William A. Rowe, Jr. wrote: At 12:12 AM 7/17/2005, [EMAIL PROTECTED] wrote: Author: ianh Date: Sat Jul 16 22:12:10 2005 New Revision: 219372 URL: http://svn.apache.org/viewcvs?rev=219372view=rev Log: This patch adds a new hook (request_status) that gets ran in proxy_handler just before the final return. This gives modules an opportunity to do something based on the proxy status. [...] new hook -- so mmn bump.. i made it a major one, hope thats ok We only bump major when we -change- an existing API or drop an API which is no longer supported. E.g. anyone using the old major might have been using something we no longer provide. A new structure member (at the end of an httpd-allocated structure) or new function are minor bumps; which this patch falls under. The user updating should not need to update their module, because the expectations when such modules were built have not changed. Well honestly, the way the MMN is bumped has been very arbitrary. If we want to go by the rules that you describe, it needs to get documented. One might actually wonder what the MMN is good for nowadays anyway, given that we have provider versioning and better defined overall versioning (ie. API compatibility between minor versions). Sander
Re: mod_cache caching the 301 Moved Permanently
[EMAIL PROTECTED] wrote: Hansjoerg Pehofer wrote: On Thu, Jul 07, 2005 at 09:22:25PM +0200, [EMAIL PROTECTED] wrote: Have you checked http://mail-archives.apache.org/mod_mbox/httpd-dev/200504.mbox/[EMAIL PROTECTED] ? It contains a small patch which was not discussed any further here. Hi, i tried your patch today. Unfortunately cache-handle-cache_obj-info.status isn't set during cache_out_filter(), but cache-handle-status is. (It gets set in mod_disk_cache.c:499 during recall_headers().) Many thanks for the feedback and the corrected patch. I checked my patch again and must admit that it does only make sense on Apache 2.1. For Apache 2.0.x your patch is the correct one. Question to the mod_cache gurus: While mod_mem_cache restores the status during recall_headers in Apache 2.0.54 it seems that mod_mem_cache does not do this in Apache 2.1.x (Maybe fixed meanwhile my latest revision of mod_mem_cache.c is 178625 and viewcvs is currently down), whereas mod_disk_cache still does this in Apache 2.1.x in file_cache_recall_mydata which is called by open_entity. Is this behaviour intended? 2.0 is quite a bit behind when it comes to mod_cache. mod_mem_cache has gotten a lot less attention in 2.1 as mod_disk_cache has. That said, in 2.1, I think we should restore status in mod_cache, not in the cache providers. Ofcourse, if that isn't possible for whatever reason, the restoration has to be done in _all_ cache providers. The above might explain the discrepancies... Sander
Re: mod_mbox and i18n
Maxime Petazzoni wrote: There's no reason the strings have to be hard coded into the C code. You can pull them out into some sort of language specific file, just like any other C program that worries about i18n. This would mean more file I/O every time mod_mbox runs, and maybe using an external library such as gettext (quite heavy stuff for mod_mbox needs). Maybe some home-made system, but I fear that it won't be fast enough. ? Why not? You can cache the results per language in memory. Honestly, that seems like a far better solution to me. XML+XSLT seems like extreme overkill if all you want is a way to have the strings change on a per-language basis. I did not proposed XML+XSLT as a solution to i18n problems. It is just an interesting system that can provide both templating-like mechanism and i18n facilities (still, not as clean as I would like). Quoting from your previous mail: - With the XML+XSLT output, these strings are in the XSLT so they can be easily translated. Two sub-solutions are available : * provide a full XSLT per language Not maintainable if you ask me. Code duplication is something we want to avoid, and having to push xsl changes to n translations seems like a bad idea. * use variables for strings and a sub XSL defining this variables depending on the language. This is, at least in my mind, not going to be one bit faster than using (cached) gettext. FWIW, I'm not too worried about i18n and mod_mbox. It's only the interface changing language anyway. Sander
Re: [vote] MODULE_MAGIC_COOKIE
William A. Rowe, Jr. wrote: At 01:33 PM 7/1/2005, William A. Rowe, Jr. wrote: I have bumped the MODULE_MAGIC_COOKIE for 2.1.7. This will be bumped again upon 2.2 release to AP22. -#define MODULE_MAGIC_COOKIE 0x41503230UL /* AP20 */ +#define MODULE_MAGIC_COOKIE 0x41503231UL /* AP21 */ The question remains, so please choose one; [ ] Revert the cookie to AP20 for httpd-2.1 and httpd-2.2 [ ] Leave the cookie at AP21 and bump again to AP22 w/httpd-2.2 [X] Get it over with already and bump now to AP22 for httpd-2.1 Sander
Re: [VOTE] mod_ftp for HTTP Server Project
Jim Jagielski wrote: Now that Covalent has released it's ERS 3.0 distribution, mod_ftp is now officially offered for donation/incubation/graduation to the ASF. mod_ftp (previously Covalent FTP) is an Apache 2.0 Protocol Module which implements FTP (RFCs 959, 1123, 2228, 2389), including such features as FTP over SSL, jailing logged-in users, extended logging, firewall awareness and limiting logins. As Covalent FTP, it has been used by numerous well-known F500 companies, and is such a real-world protocol module, and not simply an academic exercise (this is not a comment on any other protocol modules in existence, but a statement to ensure that the module has been used and tested in real-world environments by major clients). The entire code-base, including Perl test scripts for inclusion in httpd-test, is available and ready for donation into the ASF svn repos. Is there anything left for the community to work on? Or rather, do you think there is enough to do to attract a few (new) developers? Assuming the answer is yes: I therefore Call A Vote on whether we should support mod_ftp for inclusion into the Incubator and if we should accept mod_ftp upon graduation from the Incubator. +1. Sander
Re: NOTE To All Dev's!!!
William A. Rowe, Jr. wrote: I have bumped the MODULE_MAGIC_COOKIE for 2.1.7. This will be bumped again upon 2.2 release to AP22. -1. The modules are significantly disjoint, and testing for the mmn date and level between a 2.0 and 2.1 module will not produce the desired results. Given that 2.0 should remain binary compat, there is no need to bump the magic cookie. Please forgive any inconvenience this may cause, but you must rebuild all in order to continue using modules against 2.1. I don't understand the need. Let's discuss this first. Thanks, Sander
2.0.55, WAS: Re: 2.1.6 is available for veto^H^H^H^Hvoting
William A. Rowe, Jr. wrote: [...] My goal is to tag and roll 2.0 by Friday for release early next week, unless the fixes are ready sooner. There is a list of already-accepted patches in status, if anyone wants to pick some low hanging fruit for 2.0. Bill, are you volunteering for RM? I'm happy to RM FWIW, and do the 2.0.55 TR on friday. Which, by the way, will imply release around wednesday the following week given our regular own dogfood test. Thanks, Sander
Re: Proposal: Drop .Z dist file for 2.1/2.2
Paul Querna wrote: We ship with 3 to 4 different packages of the source for each release. Currently, we ship bzip2(.bz2), gzip(.gz) and old school compress (.Z) for each release. In addition, we do get .zip files for win32 too. Sizes: 12Mhttpd-2.1.6-alpha.tar.Z 5.4Mhttpd-2.1.6-alpha.tar.bz2 7.4Mhttpd-2.1.6-alpha.tar.gz So, .Z is more than twice as big as bz2. I don't see any reason to keep including it, since every modern system has gzip, or can get it. Any objections to only shipping gzip and bzip2? None from me! Sander
Re: [Fwd: Re: 404 does not delete cached entries using mod_disk_cache]
[EMAIL PROTECTED] wrote: Sorry for being persistent, but any news / comments on this? Thanks for being persistent and patient. Unfortunately, no, I don't think there is any news yet. I have gone over your patch, but not detailed enough to commit it. I'll give it another shot before friday. Sander
Re: HTTPD 2.1 (Head) Build issues for NetWare...
William A. Rowe, Jr. wrote: At 09:43 AM 6/16/2005, Brad Nicholes wrote: I have run into this one also and I still don't understand why the make is all of the sudden asking for yacc when this all worked before. Since neither mod_ssl nor BSD sockets are part of the standard NetWare build, this isn't a show stopper. But I would like to understand what happened and how to fix it. If I had to guess; * The most recent tarballs have been pulled together with SVN's absolutely bogus default of [miscellany] use-commit-times = no (see your ~/.svn/config, where you can uncomment this section and option). Bill, I wish you would stop calling things bogus without doing the research why this is the default. This means they are checkout dates, which are entirely useless. It means any dependencies that WOULD be resolved by our commit order are no longer resolved and force rebuilds. * There was an extra 'touch' to the datestamps for these files at one time; this may not have occurred in the last package. The scripts in httpd-dist/ to create the packages most certainly do touch the files. * Depending on the tool used to unpack the source tarball, that tool might not be date preserving; this would invalidate anything we attempted above to prevent rebuilding these targets. Sander
Re: HTTPD 2.1 (Head) Build issues for NetWare...
William A. Rowe, Jr. wrote: At 09:59 AM 6/16/2005, Sander Striker wrote: William A. Rowe, Jr. wrote: * The most recent tarballs have been pulled together with SVN's absolutely bogus default of [miscellany] use-commit-times = no (see your ~/.svn/config, where you can uncomment this section and option). Bill, I wish you would stop calling things bogus without doing the research why this is the default. That's reasonable; does anyone want to point me to the thread that justified this as the best-choice default? [I suspect I asked about this once before.] I remember it was a long one, but I don't have a pointer handy at this point. Back to httpd land; the question is --- is this the right choice for *our tarballs*? Which may or may not be related to the question above. In any case; this is useful metadata even for end users who build the package for the reasons I mentioned; does anyone have a desire/justification to lose the commit dates and use the RM's checkout date? Note that the scripts use svn export. IIRC that does default to use the last commit time, but I could be wrong. Sander
Re: problems w/ geronimo wiki (cache???)
Joshua Slive wrote: [Bringing [EMAIL PROTECTED] into the discussion; we just activated mod_disk_cache from 2.1-head on the apache wiki and it is broken.] Geir Magnusson Jr. wrote: We're having problems now getting to the geronimo wiki http://wiki.apache.org/geronimo/ some people get content, some people get nothing. Any ideas? mod_cache is returning: HTTP/1.1 304 Not Modified Date: Mon, 06 Jun 2005 12:56:11 GMT Server: Apache/2.1.5-dev (Unix) Connection: close to ordinary non-conditional GET requests. The result is obviously a blank page in the browser. So obviously mod_cache is not dealing correctly with 304 responses from the back-end, and is therefore rather useless at the moment. I've turned it off on the wiki. Any suggestions from [EMAIL PROTECTED] I could have sworn we had solved this a few months ago. I've seen this working with 2.1.4-dev, but I'd need to track back what rev. I don't expect to be able to look at this before wednesday :/ Justin, how's your stack of round tuits? Sander
Re: problems w/ geronimo wiki (cache???)
Justin Erenkrantz wrote: On Mon, Jun 06, 2005 at 03:40:41PM +0200, Sander Striker wrote: [...] Can we keep the caching running on port 81 on ajax? That'll make it easier to debug if I do get some time. We'd really need to see what the request/response chain is. I thought someone said that MoinMoin doesn't know how to handle 304s - if so, this doesn't make much sense. -- justin Yes, that's a good point. Where is this 304 coming from if not from Moin? The core server code nor the caching code generate a 304 when the request is non-conditional. Sander
Re: svn commit: r180333 - /httpd/httpd/branches/ssl-fips-dev
William A. Rowe, Jr. wrote: At 11:43 AM 6/6/2005, Paul Querna wrote: André Malo wrote: Sandbox of httpd/trunk/modules/ssl/ for OpenSSL 0.9.7 fips integration development Added: httpd/httpd/branches/ssl-fips-dev/ - copied from r180332, httpd/httpd/trunk/modules/ssl/ I'm not sure about any policy, but it seems better to me to branch off the whole trunk, not just a subtree (you never know, what needs to be modified finally) I agree with nd. My thinking was; 98% of the changes will be to modules/ssl code itself. 90% of the remainder are likely to be incidental bug fixes than Ben, I or anyone else working on the tree encounter. The other 10% is autoconf detection. Most autoconf can be localized in modules/ssl, but for the rest of the autoconf issues, they should be no-ops if this code is not adopted. E.g. detecting if libcrypto.so.fips (the signature hash file) exists. Contrawise, most bug fixes to head will be better reviewed if those of us working in this branch pick them up immediately. But if concensus says make this a full tree, I'll be happy to oblige. Personally I prefer entire tree branches. Sander
Re: 404 does not delete cached entries using mod_disk_cache
[EMAIL PROTECTED] wrote: Felix Enning pointed me again to an interesting question regarding mod_cache / mod_disk_cache: The following situation was observed with Apache 2.0.54 (same applies to trunk): 1. A resource gets cached. 2. The original resource gets removed from the backend (e.g on a proxied webserver, on the local disk, wherever). 3. The client sents a request that forces the cache to revalidate this entry. 4. The 404 received from the backend is correctly passed back to the client by mod_cache. 5. The client sents a request that does NOT require the cache to revalidate this entry. 6. Cache delivers the old resource that had been cached before, instead of a 404. Is this behaviour intended and compliant with the RFC? Not to my knowlegde. Given that mod_mem_cache and mod_disk_cache are doing different things is pretty much indicative that one of the two is wrong ;). The reason for this behaviour is that the remove_url function of mod_disk_cache is a dummy function (BTW: mod_mem_cache seems to really remove the cache entry in remove_url). If this behaviour is not intended I would have a look into this to create a patch. Please do! Sander
Re: mod_cache deliver 304 instead of (not so) stale cache entries
[EMAIL PROTECTED] wrote: Sander Striker wrote: [EMAIL PROTECTED] wrote: [...] Might as well not do revalidation in that case; actually that would be better, because the 304's that are returned may not even be correct. The conditions are replaced with the ones from the cache, remember? Yes, I remember, but I must admit that I am slightly confused now. When should we avoid revalidation with the conditionals from the cache? Well, we shouldn't; it's a workaround for a different bug. The workaround however would be to _never_ use the conditionals from the cache. If the original request does not contain any conditionals? This is what my patch does What I am trying to point out is that you can't use the conditionals from the cache at all if the CACHE_SAVE filter isn't being invoked. You will get a 304 based on the conditionals from the cache, which may not be correct with respect to the conditionals from the request. [..cut..] I can see the application. Are you up for submitting a patch to the default handler? :) I have attached a patch for this. Two comments: 1. I am not very familar with buckets and brigades, so please check closely if I did it correct (my tests make me think so). If I did something wrong feedback is appreciated such that I can do it better next time :-) 2. ap_meets_conditions returns 3 different values: OK, HTTP_PRECONDITION_FAILED and HTTP_NOT_MODIFIED. In my patch I assume that in all cases the response should go down the filter chain. I'll review your patch. I'll massage it into shape if needed, given your comments. Thanks, Sander
Re: mod_cache deliver 304 instead of (not so) stale cache entries
[EMAIL PROTECTED] wrote: [...] I found out that during the second request which returns a 304 the CACHE_SAVE filter, which would be able to deal with such things (- (not so) stale cache entries) is never used. The change of the conditionals in cache_storage.c starting at line 269 leads to the creation of a 304 code in the default handler and the default handler does not pass 304 responses down the filter chain. Then that is a bug. We've seen the same problem in mod_proxy. So the 304 response is delivered instead of the (not so) stale cache entry. So I created the following patch to cache_storage.c which prevents the modification or better creation of any conditionals if the original request did not contain any: No, this is what we were trying to prevent. I am aware that this forces a full request to the backend for requests without conditionals to expired resources. So I am not very happy with this solution. Maybe it is better to let the default handler pass 304 responses down the filter chain. Might as well not do revalidation in that case; actually that would be better, because the 304's that are returned may not even be correct. The conditions are replaced with the ones from the cache, remember? Some might also say that my configuration seems stupid (do disk caching for static resources, which was actually born during some tests for another problem I am currently hunting), but this problem also applies to other providers than mod_disk_cache and the document root might be on a non local disk. I can see the application. Are you up for submitting a patch to the default handler? :) Sander
Re: [VOTE] 2.2.0 Alpha on Friday
Andr Malo wrote: I'm seeing it like this: Once forked off, 2.1.x would be *stabilizing* branch, that finally leads to a 2.2.x branch, when we feel, it's stable (svn mv 2.1.x 2.2.x?). From the 2.1.x branch we tag alpha and beta releases; from *stable* 2.2.x rc and stable release. I think that's exactly the point of the odd/even system - 2.2.0 being a GA version. I see (now :-) that we should have already branched 2.1.x the first time we released a 2.1 version. +1. Sander
Re: [PATCH] mod_cache, don't always run as a quick handler.
Paul Querna wrote: Okay, because of the quirky behavior of a 'sometimes' cached page, this one had me going in circles for a little while. What this patch does, is add a new command to mod_cache, 'CacheRunAfterOthers_RenameThisCmd'[1] The effect this has is to run mod_cache as a normal handler, instead of a Quick Handler. This means all the other Translate Name, Map to Storage, and Fixup hooks are ran. These include mod_rewrite and mod_alias, among others. +1. And FWIW, I like Brian Atkins' solution to add an extra flag to CacheEnable. Sander
Reverting vs branching, WAS: Re: svn commit: r169705 - in /httpd/httpd/trunk: include/util_ldap.h modules/ldap/util_ldap.c
Paul Querna wrote: [EMAIL PROTECTED] wrote: Author: bnicholes Date: Wed May 11 15:34:18 2005 New Revision: 169705 URL: http://svn.apache.org/viewcvs?rev=169705view=rev Log: Add the LDAPVerifyServerCert directive to util_ldap to force verification of a server certificate when establishing an SSL connection to the LDAP server Modified: httpd/httpd/trunk/include/util_ldap.h httpd/httpd/trunk/modules/ldap/util_ldap.c Ack. This commit means that httpd/trunk now depends on apr-util/trunk. Before this you were able to run httpd/trunk using APR-Util 1.1.x. Which is a no-go. Please revert. This effectively kills any httpd alphas until APR-Util 1.2.0 is released. I believe we should uphold the policy of using only released versions of a dependency. +1. I don't see an APR-Util 1.2.0 coming very soon. The APR-DBD code could still use more love. This is just an example of why I wanted to branch trunk to 2.1.x. I have nothing against adding this specific feature -- it just happens to require a non-released version of APR-Util. Ideas for a solution that doesn't involve waiting for APR-Util 1.2.0? Yes. We could do the branch... Sander
Re: [PROPOSAL] Branch 2.1.x on May 13
Jim Jagielski wrote: William A. Rowe, Jr. wrote: From discussion - I see us branching 2.1.x anyways, but still object since we will now be maintaining two or three backports for every bugfix commit to trunk/. If the trees are so in sync that the same patch applies it's trivial to do the backports. Humbly suggest this isn't the conclusion we reached at AC Las Vegas, and suggest it's still the wrong solution to a non-problem. If there was a 2.1.x beta out there right now I would agree it was a non-problem. It would be a good thing to restate what the conclusions were at AC 2004 US. Bill makes some good points... it seems that branching would simply be renaming trunk. The good thing is that with svn this is cheap and easy, but will it really do what we want? Also, the gotta backport this to yet another branch issue is valid. No it isn't. That's the whole point of stabilizing. No more worries about whether someone actually reviewed the slew of changes the night before the RM intended to tag. The backport issue will still stay FWIW. If not now, it will come at the time we have 2.0 and 2.2 out there, and trunk is at 2.3-dev. It's not like we can drop support for 2.0 then. In other words, trunk is 2.1 anyway, so what does a branch provide? I would say it's a perception advantage mostly. Well, it would let people continue to have a place where they can develop the larger features/refactoring jobs. That's indeed only a handful of people, but at the same time a group of people who do a lot of work. Sander
Re: mod_cache caching the 301 Moved Permanently
[EMAIL PROTECTED] wrote: The problem seems to be, that the proxied backend server that is cached via mod_disk_cache originally delivers HTTP status 301 and the Location http://www.beach-clothing.com/where-to-buy/, but once cached mod_disk_cache delivers HTTP status 200 instead of 301 (but correctly redelivering the Location header). I have not proved this for myself so far, but this seems the problem to me. This wouldn't surprise me one bit. The 2.1 branch has seen quite a bit of churn in this area. Any chance you could give 2.1 a go and see if that works correctly? Sander
Re: 2.0.54 release candidate tarball available for testing
Sander Striker wrote: Hi, As usual the tarballs are at: http://httpd.apache.org/dev/dist/ Please give 2.0.54 a whirl and report any problems (or successes) ;) Given the reponses and the fact that it has been hosting most of our own webtraffic for a bit I conclude it is looking good for release. I'll push it out tomorrow. Bill, do you happen to have time to get some win32 balls up on dev/dist so I can push it out together with the other tarballs? Thanks, Sander
2.0.54 release candidate tarball available for testing
Hi, As usual the tarballs are at: http://httpd.apache.org/dev/dist/ Please give 2.0.54 a whirl and report any problems (or successes) ;) Thanks, Sander
Re: svn commit: r160909 - httpd/httpd/branches/2.0.x/modules/experimental/mod_cache.c
Brad Nicholes wrote: This broke the NetWare build so I fixed it. I never saw the same problem in trunk so I'm not sure where this patch came from in the first place. I don't have a problem with redefining new, I just need it fixed so that NetWare will build before Sander tags the tree. Yah, that patch would have been me doing the voted in backports. Sander
NetWare mod_dav import file, WAS: Re: svn commit: r160636 - httpd/httpd/trunk/modules/dav/main/dav.imp
[EMAIL PROTECTED] wrote: Author: bnicholes Date: Fri Apr 8 16:03:45 2005 New Revision: 160636 URL: http://svn.apache.org/viewcvs?view=revrev=160636 Log: Update the mod_dav import file for NetWare I assume something similar has to be done for 2.0.x? Sander
Re: svn commit: r160645 - httpd/httpd/branches/2.0.x/STATUS
[EMAIL PROTECTED] wrote: Author: wrowe Date: Fri Apr 8 17:38:46 2005 New Revision: 160645 @@ -208,7 +209,7 @@ * Win32: Move call to mpm_service_install to the rewrite_args hook from the post_config hook. http://svn.apache.org/viewcvs?view=revrev=154319 - +1: stoddard, striker + +1: stoddard, striker, wrowe (as corrected in subsequent patches) Bill, could you please add the revisions of these subsequent patches? * mod_version: New Module, Backport from trunk. http://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/metadata/mod_version.c (Also need to backport docs, and build system stuff.) - +1: pquerna, jerenkrantz + +1: pquerna, jerenkrantz, wrowe (trivial, would even be cool in 1.3) Paul, Justin, could you either provide me with a complete patch against 2.0.x or add the revisions I need to merge? Thanks, Sander
Re: [NOTICE] Tagging 2.0.54, WAS: Re: Time for 2.0.54?
Sander Striker wrote: Sander Striker wrote: Hi guys, It's been almost 2 months since 2.0.53. Think it is time for 2.0.54 yet? I'll volunteer to RM if that is a yes ;) Just a heads up: I'm planning on starting the TR of 2.0.54 on thursday night (UTC +1). And ofcourse it's friday night already... I would be thankful if someone could start backporting the suggested backports with enough votes in STATUS. If noone has any round tuits, I'll get to it before doing the tag. Noone seemed to have any spare tuits, so I guess that I'm the unfortunate backporter. I would like to backport all things that got enough votes so that STATUS actually shrinks a bit. Given I don't want to mess this up too much I'd rather start doing this tomorrow during the day. If anyone feels lucky today, don't hesitate to take on some backports yourself, especially if it is your patch... Thanks, Sander
Re: svn commit: r160441 - httpd/httpd/trunk/httpd.dsp
[EMAIL PROTECTED] wrote: Author: wrowe Date: Thu Apr 7 12:19:58 2005 New Revision: 160441 URL: http://svn.apache.org/viewcvs?view=revrev=160441 Log: Catch up with Apache.exe-httpd.exe rename; it seems svn rn can't be combined with svn commit and source changes. Can you please save these comments for the dev@ list and not put them in the log message? What exactly didn't go as you expected? Sander
[NOTICE] Tagging 2.0.54, WAS: Re: Time for 2.0.54?
Sander Striker wrote: Hi guys, It's been almost 2 months since 2.0.53. Think it is time for 2.0.54 yet? I'll volunteer to RM if that is a yes ;) Just a heads up: I'm planning on starting the TR of 2.0.54 on thursday night (UTC +1). I would be thankful if someone could start backporting the suggested backports with enough votes in STATUS. If noone has any round tuits, I'll get to it before doing the tag. Thanks, Sander
Re: Forthcoming 2.2 - Win32 specific questions
William A. Rowe, Jr. wrote: 'Apache' was our program. It became our project. It's become our entire organization. In 2.2, I -will- be changing the default location for the Win32 installer from %programsdir%\Apache Group\Apache2\ over to %programsdir%\Apache Software Foundation\Apache HTTP Server 2.2\. +1. [...] So can I have a quick vote before beta to rename our program to 'httpd.exe' on Windows, matching our Unix builds? +1.
[PATCH] mod_proxy_http
Hi,
It seems like mod_proxy_http is being cute and not sending an EOS
bucket down the rest of the filter stack when it only receives
headers. This (most likely) causes mod_cache's cache_save_filter
to not be run when it receives a 304.
Unfortunately I cannot 100% reproduce this locally, but the behaviour
seems to be consistent on a solaris production machine which I can't
fiddle about with too much (which includes testing this patch short
term).
In short: Some eyes please...
Thanks,
Sander
---
Index: modules/proxy/mod_proxy_http.c
===
--- modules/proxy/mod_proxy_http.c (revision 157814)
+++ modules/proxy/mod_proxy_http.c (working copy)
@@ -1331,9 +1331,21 @@
}
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,
proxy: end body send);
-} else {
+}
+else {
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,
proxy: header only);
+
+/* Pass EOS bucket down the filter chain */
+e = apr_bucket_eos_create(c-bucket_alloc);
+APR_BRIGADE_INSERT_TAIL(bb, e);
+if (ap_pass_brigade(r-output_filters, bb) != APR_SUCCESS
+|| c-aborted) {
+/* Ack! Phbtt! Die! User aborted! */
+backend-close = 1; /* this causes socket close below */
+}
+
+apr_brigade_cleanup(bb);
}
} while (interim_response);
Reformat httpd-win.conf
Hi, Rather than sending a patch (since it isn't readable) you'll find a reformatted httpd-win.conf attached. It uses the new IfModule style, and is indented as with the non-win32 counterpart. Objections? Sander # # Based upon the NCSA server configuration files originally by Rob McCool. # # This is the main Apache server configuration file. It contains the # configuration directives that give the server its instructions. # See URL:http://httpd.apache.org/docs-2.1/ for detailed information about # the directives. # # Do NOT simply read the instructions in here without understanding # what they do. They're here only as hints or reminders. If you are unsure # consult the online docs. You have been warned. # # The configuration directives are grouped into three basic sections: # 1. Directives that control the operation of the Apache server process as a # whole (the 'global environment'). # 2. Directives that define the parameters of the 'main' or 'default' server, # which responds to requests that aren't handled by a virtual host. # These directives also provide default values for the settings # of all virtual hosts. # 3. Settings for virtual hosts, which allow Web requests to be sent to # different IP addresses or hostnames and have them handled by the # same Apache server process. # # Configuration and logfile names: If the filenames you specify for many # of the server's control files begin with / (or drive:/ for Win32), the # server will use that explicit path. If the filenames do *not* begin # with /, the value of ServerRoot is prepended -- so logs/foo.log # with ServerRoot set to @@ServerRoot@@ will be interpreted by the # server as @@ServerRoot@@/logs/foo.log. # # NOTE: Where filenames are specified, you must use forward slashes # instead of backslashes (e.g., c:/apache instead of c:\apache). # If a drive letter is omitted, the drive on which Apache.exe is located # will be used by default. It is recommended that you always supply # an explicit drive letter in absolute paths, however, to avoid # confusion. # ### Section 1: Global Environment # # The directives in this section affect the overall operation of Apache, # such as the number of concurrent requests it can handle or where it # can find its configuration files. # # # ServerRoot: The top of the directory tree under which the server's # configuration, error, and log files are kept. # # NOTE! If you intend to place this on an NFS (or otherwise network) # mounted filesystem then please read the LockFile documentation (available # at URL:http://httpd.apache.org/docs-2.1/mod/mpm_common.html#lockfile); # you will save yourself a lot of trouble. # # Do NOT add a slash at the end of the directory path. # ServerRoot @@ServerRoot@@ # # ScoreBoardFile: File used to store internal server process information. # If unspecified (the default), the scoreboard will be stored in an # anonymous shared memory segment, and will be unavailable to third-party # applications. # If specified, ensure that no two invocations of Apache share the same # scoreboard file. The scoreboard file MUST BE STORED ON A LOCAL DISK. # #ScoreBoardFile logs/apache_runtime_status # # PidFile: The file in which the server should record its process # identification number when it starts. # PidFile logs/httpd.pid # # Timeout: The number of seconds before receives and sends time out. # Timeout 300 # # KeepAlive: Whether or not to allow persistent connections (more than # one request per connection). Set to Off to deactivate. # KeepAlive On # # MaxKeepAliveRequests: The maximum number of requests to allow # during a persistent connection. Set to 0 to allow an unlimited amount. # We recommend you leave this number high, for maximum performance. # MaxKeepAliveRequests 100 # # KeepAliveTimeout: Number of seconds to wait for the next request from the # same client on the same connection. # KeepAliveTimeout 15 ## ## Server-Pool Size Regulation (MPM specific) ## # WinNT MPM # ThreadsPerChild: constant number of worker threads in the server process # MaxRequestsPerChild: maximum number of requests a server process serves IfModule mpm_winnt_module ThreadsPerChild 250 MaxRequestsPerChild 0 /IfModule # # Listen: Allows you to bind Apache to specific IP addresses and/or # ports, instead of the default. See also the VirtualHost # directive. # # Change this to Listen on specific IP addresses as shown below to # prevent Apache from glomming onto all bound IP addresses (0.0.0.0) # #Listen 12.34.56.78:80 Listen @@Port@@ # # Dynamic Shared Object (DSO) Support # # To be able to use the functionality of a module which was built as a DSO you # have to place corresponding `LoadModule' lines at this location so the # directives contained in it are actually available _before_ they are used. # Statically compiled modules (those listed by `httpd -l') do not need # to be loaded here. # # Example: # LoadModule foo_module modules/mod_foo.so # LoadModule actions_module
Time for 2.0.54?
Hi guys, It's been almost 2 months since 2.0.53. Think it is time for 2.0.54 yet? I'll volunteer to RM if that is a yes ;) Sander
buildconf.nice, WAS: Re: svn commit: r158303 - httpd/httpd/trunk/buildconf
Justin Erenkrantz wrote: --On Tuesday, March 22, 2005 3:22 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Of course! Now I'm on the same page with you. Actually, I believe a buildconf.nice is a better solution (for reasons in my other note.) We really have no say-so about what is sitting in the directory above our httpd snapshot. It only matters if the directory is present and contains the files we need. I just think a buildconf.nice would be overkill here. -- justin I find myself agreeing with that... Sander
Re: svn commit: r158303 - httpd/httpd/trunk/buildconf
William A. Rowe, Jr. wrote: At 11:26 PM 3/19/2005, [EMAIL PROTECTED] wrote: Author: pquerna Date: Sat Mar 19 21:26:22 2005 New Revision: 158303 URL: http://svn.apache.org/viewcvs?view=revrev=158303 Log: Test for APR and APR-Util one directory bellow httpd too. I like not having to put them inside srclib. grumf I'm not keen on this change, since it complicates things unnecessarily - some day we discover a tag and roll organized like this out of the blue? What do you mean? I thought that the future goal was to unbundle apr* in httpd releases? So you're afraid of tagged and rolled (actually only rolled, since tags don't include apr* anyway) tarballs that don't contain srclib/apr* before we actually wish to unbundle? Isn't that the RM's responsibility? Does config.nice not do what you want? Especially if you rename it config.me with all your absolute options that you don't tweak? I don't see how that would help towards the unbundling goal. Also for development purposes it's way more convenient to allow apr* next to httpd as to require it be in srclib/. Sander
Re: Rolling 2.1.4...
Sander Striker wrote: Justin Erenkrantz wrote: On Mon, Mar 14, 2005 at 08:03:43PM -0800, Paul Querna wrote: I would like to roll the 2.1.4 alpha right after APR 1.1.1 is released. I plan on rolling APR tonight or Tuesday morning. If there arent any problems, I am hoping to create 2.1.4 on Thursday. Any big outstanding issues? As far as I can tell, the Win32 fixes still haven't been backported to APR 1.1.x. Or, am I missing something? -- justin I'll go and look into this tonight if OtherBill *nudge* *nudge* doesn't beat me to it. FWIW, I've already gone ahead and tagged 2.1.4. Work is now somewhat getting in the way, so I'll get to rolling this afternoon. Sander
2.1.4 available for testing
Hi all, There are some 2.1.4-alpha tarballs waiting to be tested at: http://httpd.apache.org/dev/dist/ Please report back with any problems. Thanks for testing! Sander
Re: 2.1.4 available for testing
Sander Striker wrote: Hi all, There are some 2.1.4-alpha tarballs waiting to be tested at: http://httpd.apache.org/dev/dist/ Please report back with any problems. Thanks for testing! FWIW: +1 Tested on: Linux (Ubuntu - Warty Warthog) Win32 (XP SP2)* Sander *) Source from the tag, no zip ball is available at this time.
Re: Rolling 2.1.4...
Paul Querna wrote: I would like to roll the 2.1.4 alpha right after APR 1.1.1 is released. I plan on rolling APR tonight or Tuesday morning. If there arent any problems, I am hoping to create 2.1.4 on Thursday. Any big outstanding issues? Nope, just the wait on APR IMO. FWIW, I might get to 2.1.4 before thursday if that is any help. Sander
Re: Rolling 2.1.4...
Justin Erenkrantz wrote: On Mon, Mar 14, 2005 at 08:03:43PM -0800, Paul Querna wrote: I would like to roll the 2.1.4 alpha right after APR 1.1.1 is released. I plan on rolling APR tonight or Tuesday morning. If there arent any problems, I am hoping to create 2.1.4 on Thursday. Any big outstanding issues? As far as I can tell, the Win32 fixes still haven't been backported to APR 1.1.x. Or, am I missing something? -- justin I'll go and look into this tonight if OtherBill *nudge* *nudge* doesn't beat me to it. Sander
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Justin Erenkrantz wrote: On Tue, Mar 08, 2005 at 03:57:55AM +0100, Sander Striker wrote: Hi, Currently CacheIgnoreCacheControl On only ignores Cache-Control: no-cache and Pragma: no-cache. I'd like to add ignoring Cache-Control: max-age=... and Cache-Control: min-fresh=... as well. This would give the admin more control, and would also make the directive slightly more intuitive IMO. This because different browsers do different things. One will send a Cache-Control: no-cache on a refresh, and one will send a Cache-Control: max-age=... It would be nice if the effect would be the same for both. Thoughts? While I think this is a good idea, I'd like to consider renaming this particular directive as I think the name is really confusing. Does that mean you want me to hold off on committing this patch pending a directive rename? Isn't that a seperate issue? My concern is that CacheIgnoreCacheControl only refers to the request's Cache-Control not the origin response's Cache-Control header. But, I like that separation because having it refer to both is too coarse-grained, I think. Definately agreed. Ignoring response Cache-Control is in another league than ignoring the request Cache-Control. But, I don't have any real ideas for what an alternative name is. -- justin CacheIgnoreServerCacheControl? Sander
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Justin Erenkrantz wrote: It's just that you brought up the point of making the directive more intuitive - and I have problems from the word go on this particular directive being intuitive. It's not. In order to understand what this directive does, you need to know what Cache-Control from the RFC means - and that's not intuitive. I'd like something that expresses the concept that we will serve cached content even if the client asks for 'fresh' content. Agreed. The closest I can come up with is 'CacheServeStale' - but that's not quite right or even precise either. Cache-Control is per definition a bit of a tough thing to translate to a term like Stale or Fresh, since it can require both. [...] Per above, I don't like the phrase Cache-Control. -- justin Fair enough. What about: CacheIgnoreClientAgeRequirements ? A bit long maybe. Sigh. I'm not very good at coming up with short yet descriptive directive names I'm afraid. Sander
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Eli Marmor wrote: [...] CacheForOffline? (or Cache4Offline) Offline browsing is the main case where you need such absolute caching. But it requires you to cache EVERYTHING. Including dynamic content, and even different content according to different POST input. Maybe two directives are needed, one for using the cache only if the cookies are the same. All of that requires changing the caching mechanism to keep POST input, cookies, etc. I think you just proved Justins point. Above is all about response Cache-Control. The current CacheIgnoreCacheControl only affects request Cache-Control. Confuzzled yet ;) :) Sander
request_rec, no_cache
Hi, There is a no_cache field in the request rec. It only seems to be set by mod_negotiation. Given the big chunk of comments at mod_negotiation.c:2920 I'm not sure if we actually need this field, or if we can reach the same result in another fashion (without some dodgy flag). Thoughts? Sander
Re: [VOTE] 2.1.3 as beta
Jim Jagielski wrote: I vote +1 for a beta. Ditto. Sander
[PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Hi,
Currently CacheIgnoreCacheControl On only ignores Cache-Control: no-cache
and Pragma: no-cache. I'd like to add ignoring Cache-Control: max-age=...
and Cache-Control: min-fresh=... as well.
This would give the admin more control, and would also make the directive
slightly more intuitive IMO. This because different browsers do different
things. One will send a Cache-Control: no-cache on a refresh, and one will
send a Cache-Control: max-age=... It would be nice if the effect would
be the same for both.
Thoughts?
Sander
Log:
Make CacheIgnoreCacheControl do what it implies, at least when it comes to
freshness checks.
* modules/cache/cache_util.c
(ap_cache_check_freshness): Ignore CacheControl: max-age and min-fresh
as well if CacheIgnoreCacheControl is set.
Index: modules/cache/cache_util.c
===
--- modules/cache/cache_util.c (revision 156480)
+++ modules/cache/cache_util.c (working copy)
@@ -122,6 +122,9 @@
char *val;
apr_time_t age_c = 0;
cache_info *info = (h-cache_obj-info);
+cache_server_conf *conf =
+ (cache_server_conf *)ap_get_module_config(r-server-module_config,
+cache_module);
/*
* We now want to check if our cached data is still fresh. This depends
@@ -162,9 +165,6 @@
if (ap_cache_liststr(NULL, pragma, no-cache, NULL)
|| ap_cache_liststr(NULL, cc_req, no-cache, NULL)) {
-cache_server_conf *conf =
- (cache_server_conf *)ap_get_module_config(r-server-module_config,
-cache_module);
if (!conf-ignorecachecontrol) {
/* Treat as stale, causing revalidation */
@@ -172,7 +172,7 @@
}
ap_log_error(APLOG_MARK, APLOG_INFO, 0, r-server,
- Incoming request may be asking for a uncached version of
+ Incoming request is asking for a uncached version of
%s, but we know better and are ignoring it,
r-unparsed_uri);
}
@@ -197,7 +197,8 @@
}
/* extract max-age from request */
-if (cc_req ap_cache_liststr(r-pool, cc_req, max-age, val)) {
+if (!conf-ignorecachecontrol
+ cc_req ap_cache_liststr(r-pool, cc_req, max-age, val)) {
maxage_req = apr_atoi64(val);
}
else {
@@ -234,7 +235,8 @@
}
/* extract min-fresh */
-if (cc_req ap_cache_liststr(r-pool, cc_req, min-fresh, val)) {
+if (!conf-ignorecachecontrol
+ cc_req ap_cache_liststr(r-pool, cc_req, min-fresh, val)) {
minfresh = apr_atoi64(val);
}
else {
Re: [VOTE] 2.1.3 as beta
William A. Rowe, Jr. wrote: jakarta-tomcat-dev reports Gump can't build, but since they haven't given us details so not much we can do about it. Fails to even build on Win32. -1 for beta on 2.1.3. I think we passed the 2.1.3 station already. Onward to 14 ++1 to Sander's efforts to roll out 2.1.4 ... let's get it right (at least, let's have something that builds, irrespective of it has the features folks want.) So what is failing to build? 2.1.3? Or trunk? Only on win32, or on other platforms as well? Can you reproduce? I've chided tomcat-dev to bother to report to us what their Gump results are. Would go a long ways to solving a problem we didn't know exists. It seems to build fine in the ASF wide Gump run on brutus: http://brutus.apache.org/gump/public/apache-httpd/index.html Sander
Re: mod_cache
Justin Erenkrantz wrote:
--On Friday, March 4, 2005 11:55 PM +0100 Sander Striker
[...]
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? =)
Sure thing. Done (r156304).
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. [...]
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.
Ah, the coin is dropping here. Since it is a filter, cache save can
be called multiple times in succession, with different brigades. Makes
total sense.
[...]
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.
Well, I'm first going to check if we are doing the right thing with
cached 301s (I saw some wonkiness earlier, but need to reverify). If
that is all good, I'll add 302 support.
[...]
/* 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.
I'm fairly sure it would. Considering we have the final response headers,
and the original request headers, this is just like a normal request.
So ap_meets_condition should do the trick just fine when it comes to
figuring out what to send back to the client. I'll test, and if it works,
I'll commit it.
Okay, back to your real bug:
[...]
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.
Correct.
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.
What is that doing there, second guessing its caller (mod_cache)?!
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 Not modified on revalidation with an updated Expires
header.
- At mod_cache.c:533, we restore the cached handle.
- Around mod_cache.c:658, we merge in the updated response headers
- Then at mod_cache.c:683, we call the provider to store the headers.
- Then, we hit store_headers in mod_disk_cache.
- Because mod_disk_cache *had* a stale response, it would have loaded
the stale headers into its handle.
- Hence, the check at mod_disk_cache.c:532 will fail because hfd is
'valid.'
- We never update the cached headers with the new Expires header
Can you confirm this sequence?
Yes, I can. Sheesh.
I'm thinking we shouldn't even check for
the !hfd case anyway. That check has probably been there forever and
was likely to be completely bogus from the start. What do you think?
I completely agree. So much even that I just committed it (r156306).
Why are we storing the header fd in the disk object anyways? I haven't
gone through mod_disk_cache.c yet, but at least for store_headers() it
doesn't seem to make any sense.
When it comes to store_headers(), shouldn't that be done using a temp
file and moving it into place atomically just like store_body? Are
we relying on OS buffering and header size being small enough to pull
that off? Or am I just being paranoid? :)
Sander
Re: [PATCH] mod_cache: Use provider API
Justin Erenkrantz wrote: --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. +1 (concept). Sander
Re: [PATCH] mod_cache: Use provider API
Sander Striker wrote: Justin Erenkrantz wrote: --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. +1 (concept). Huh?! In that same thread justin had a nice comment: place bag over head I'll go do that now. FYI, this happens if you try and get your mail sorted out over two years and you forget to sort it by date in your mailer... Sander 'Doh' Striker
Re: [VOTE] 2.1.3 as beta
Justin Erenkrantz wrote: 2.1.3 tarballs at: http://httpd.apache.org/dev/dist/ I'd like to get enough votes for 2.1.3 to be a beta and commence the feature freeze towards a 2.2.0 GA. As we discussed at ApacheCon in November (over three months ago), this would mean we create a 2.2.x branch from the 2.1.3 tag and bump trunk to 2.3.0. Given the fixes on trunk that went in since 2.1.3, I'd like to see a 2.1.4, and branch off of that. I'll even volunteer to take care of TR'ing 2.1.4 upcoming thursday. I feel this takes care of the mod_dav exports issue as well. By this point, I think that if a super-cool feature hasn't made it in yet, it's time to admit that the feature missed the boat and it needs to wait until 2.4. I'm tired of waiting for 2.2 when there are excellent features in our trunk that are being held up for non-existent patches. +1. I've been one of the people causing the holdup with my preference of getting the AAA user authentication/group membership split in 2.2. Let's not have wishful thinking keep up 2.2. I assume we are in agreement that the current AAA discussion shouldn't hold up moving to 2.2 either. Sander
Re: mod_cache
Sander Striker wrote:
Justin Erenkrantz wrote:
Sander Striker wrote:
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.
Well, I'm first going to check if we are doing the right thing with
cached 301s (I saw some wonkiness earlier, but need to reverify). If
that is all good, I'll add 302 support.
I'm fairly sure this doesn't work too well yet. See below.
[...]
/* 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.
I'm fairly sure it would. Considering we have the final response headers,
and the original request headers, this is just like a normal request.
So ap_meets_condition should do the trick just fine when it comes to
figuring out what to send back to the client. I'll test, and if it works,
I'll commit it.
It works (gave the correct results on cached, cached revalidating, not
cached)
so I committed it (r156330).
However, I do think you are right that ap_meets_conditions() doesn't do the
right thing. But that is in general, not just in this case. It doesn't
seem to take responses other than 2xx into account. In those cases it shouldn't
return a 304, yet it does. We'll have to visit all the places where
ap_meets_conditions() is called to make sure r-status is set, and check
r-status in ap_meets_conditions() to fix this.
Luckily for us, there is more work left even in mod_cache. Right now,
whenever we hit a Cache-Control: no-cache in the request, the cache declines
to handle the request, while it could be handling it (be it with a required
validation request to the backend). That would be a lot more efficient.
And within bounds of the spec.
Furthermore, Cache-Control: max-age=0 or even max-age=X seems to be completely
ignored. A response is given back with an Age header with a larger value then
what max-age was set to in the request.
Sander
Re: mod_cache
Justin Erenkrantz wrote: Sander Striker wrote: [...] Luckily for us, there is more work left even in mod_cache. Right now, whenever we hit a Cache-Control: no-cache in the request, the cache declines to handle the request, while it could be handling it (be it with a required validation request to the backend). That would be a lot more efficient. And within bounds of the spec. I'm not sure what you mean. Do you mean that if we get a Cache-Control: no-cache, that we should attempt to treat it as mandatory revalidation of the content? Exactly. Interesting. Right now, we just get out of the way. Right. We don't have to AFAUI, as long as we revalidate. One approach would be to remove the no-cache check and move it down into ap_cache_check_freshness() and make our response always be stale in this case. *nod* Furthermore, Cache-Control: max-age=0 or even max-age=X seems to be completely ignored. A response is given back with an Age header with a larger value then what max-age was set to in the request. This *should* be handled by ap_cache_check_freshness(). I'll admit that I haven't spent a lot of time in there. On a cursory look, it seems that it should be handling this correctly. That's what I initially thought when I glanced over it. Then I started wondering why headers are retrieved from h-req_hdrs, instead of r-headers_in. I noticed we save the request headers of the request that got a resource into the cache. Are we maybe mistakenly using those stored headers instead of the ones from the current request? I need to go over the code, but this is what popped into my head on first glance. Sander
Re: mod_cache
Justin Erenkrantz wrote: Sander Striker wrote: I completely agree. So much even that I just committed it (r156306). Why are we storing the header fd in the disk object anyways? I haven't gone through mod_disk_cache.c yet, but at least for store_headers() it doesn't seem to make any sense. It's not really the 'disk' object per se - it's part of mod_disk_cache's private cache handle. When we open the cache handle, we also open the associated file descriptors in open_entity to ensure that we have something valid cached. We then use those open descriptors in recall_headers and recall_body later on. Right. Note that we're a little tricky and we partially read the header file in open_entity to get some meta-data via file_cache_recall_mydata, but we hold off parsing the full MIME headers from disk until recall_headers time. Gotcha. When it comes to store_headers(), shouldn't that be done using a temp file and moving it into place atomically just like store_body? Are we relying on OS buffering and header size being small enough to pull that off? Or am I just being paranoid? :) Yes, there's probably a race condition here. However, store_headers is only called once, so the window is relatively small compared to store_body which can be called multiple times. Feel free to have at it. ;-) *grin* Will do. Sander
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
mod_cache
Hi,
I'm going over mod_cache and I'm wondering about some things:
--
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).
--
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.
--
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.
--
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()?
Sander
[PATCH] Handle conditional requests in mod_dav
Hi,
The point of this small patch is to allow mod_dav to take an easy
out instead of actually going through the (expensive) delivery
step, in case of a conditional request. Think of cache
validating requests for instance.
I found this interesting because of the potential of serving
content straight from a SVN repository, while retaining
near static content performance*. That is, with mod_cache
enabled.
*) Ofcourse opening the repository on each connection is a
penalty, but hey, that needs addressing elsewhere.
Makes sense?
Sander
---
Log:
* modules/dav/main/mod_dav.c
(dav_method_get): Handle conditional requests.
Index: modules/dav/main/mod_dav.c
===
--- modules/dav/main/mod_dav.c (revision 153370)
+++ modules/dav/main/mod_dav.c (working copy)
@@ -813,6 +813,7 @@
{
dav_resource *resource;
dav_error *err;
+int status;
/* This method should only be called when the resource is not
* visible to Apache. We will fetch the resource from the repository,
@@ -836,6 +837,12 @@
return dav_handle_err(r, err, NULL);
}
+/* Handle conditional requests */
+status = ap_meets_conditions(r);
+if (status) {
+ return status;
+}
+
if (r-header_only) {
return DONE;
}
RE: UNIX MPMs [ot?]
From: Leif W [mailto:[EMAIL PROTECTED] Sent: Thursday, February 10, 2005 3:10 PM [...] It's already a huge list of workaround and compatibility and portability for an admin could be a nightmare. I do not know if there are even more security wrappers needed for other language modules. Can anyone add to the list some things which might commonly be used in concert? Is there any direction given from the top of the Apache group in regards to what gets attention? No, there is not. The committers are free to work on what they want. In the message on the suPHP list, it is implied that there is in general a mentality that security is not a priority Given the way we handle security issues I don't think this remark will hold water. (at least regarding setuid per request as perchild MPM would like to do), Apparently there are a lot of people with the itch, but nobody scratching it. only competing with MS/IIS. Not even that. I mean, it's fun to watch our marketshare rise every month, but that's not what the ASF is all about. I'm not implying anything, I don't know what to believe, so that's why I ask. I'm just trying to understand where the breakdown is. A feature that people want, the lack of which spawns a sloppy slew of incompatible workarounds, but no one around to respond and code it or fix what's available. Well, we are volunteers you know ;). I'm sure you could find someone to work on perchild on a contract basis, making your itch (one of) the developers itch. Or even an external party who would submit patches. The strength of Apache was always *nix, so why abandon security on *nix for the sake of portability to Windows? There's more to it than just portability to Windows. It's the natural impression given by first glance of the timeline of events, not an accusation. Or is it just coincidence that someone (or many people) lost interest in perchild and there's been noone to pick up the slack, Correct. and other people just happened to want to increase portability to windows? Portability in general. But this is all contained in the APR project, on top of which httpd-2.x is built. Also people worked on a lot of other things during last year. Just look at the Changelog, the commit messages etc, to see what I mean. I mean, I like having a windows port, because I can at least practice using Apache somewhat, and it expands the development platform, but I won't ever, ever, EVER run it on Windows in production, simply because I'd never run Windows in production. Not all administrators are in a position where they can refuse to run Windows. Except insofar as to show Windows users a shining example of free software, and offer the idea of using an entire OS filled with shining examples of free software engineering. ;-) Toungue in cheek of course, with the ugly little problems such as this code abandonment of vital features at the back of my mind. Well, what is vital depends on context. Apparently it isn't as vital, since 2.x is certainly used without this vital mpm. Agreed, it would be very nice to see perchild development picked up again. Or metux integrated in the main distro (it'd need review and all that, and ofcourse desire from the metux developers to do so). For me personally, it isn't a big enough itch to start scratching it. Proxy and caching are a lot higher on my personal agenda. As are some other features I still am desperately seeking the time for to work on. I don't mean to start an OS flame war, so please don't respond with that in mind. :-) If other people would like to use Windows, it takes nothing away from me, I'm just stating opinion based on my own interaction and experience with Apache, Win, and *nix (Linux FreeBSD). The problem is that you drag in the *nix vs Windows argument. Why do we need to bother with that at all? Sander
Entity headers in 304 reponse, WAS: RE: svn commit: r152973 - in httpd/httpd/trunk/modules/cache: cache_storage.c mod_cache.c mod_cache.h mod_disk_cache.c
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 09, 2005 2:39 AM New Revision: 152973 [...] +/* RFC 2616 10.3.5 states that entity headers are not supposed + * to be in the 304 response. Therefore, we need to load in the + * cached headers before we update the cached headers. That's not how I read that section. 14.26 has some specific text stating cache-related header fields should be included. Sander
RE: Entity headers in 304 reponse, WAS: RE: svn commit: r152973 - in httpd/httpd/trunk/modules/cache: cache_storage.c mod_cache.c mod_cache.h mod_disk_cache.c
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 09, 2005 6:20 PM [...] Hence, the response headers from the origin server on a 304 response aren't guaranteed to be complete. So, what this commit does now is load in the stored cached response headers and interleaving them with the headers we just received as part of the 304 response - retaining the just-received headers if there is overlap. Then, we're updating our cache entry with this new merged set of headers. Yeah, I misread the comment. The issue here is that you can't just take the response headers from a 304 header and use them and them alone to update the cache: you need to 'merge' in what you already have to be complete. Sure. As an aside, see line 934 in modules/http/http_filters.c for what httpd sends on a 304: all other header fields are stripped. Ah yes, makes sense. Nice to have a guard on the way out. Or, do you see a better way? Or, is there a way to make the comment clearer? I think I've clarified the comment slightly in rev 153104. But honestly, it was just me. Sander
Renaming proxy backends
Hi, Anyone object to me renaming proxy_[ajp|balancer|connect|ftp|http].c to mod_proxy_[ajp|balancer|connect|ftp|http].c? Reason: IfModule mod_proxy_http.c ... /IfModule I had to look a few times to figure out I had to leave out the mod_ part. Since all the other modules start with mod_, I'd like to make this consistent. Sander
RE: re-do of proxy request body handling - ready for review
-Original Message- From: Graham Leggett [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 10:39 PM To: dev@httpd.apache.org Subject: Re: re-do of proxy request body handling - ready for review Justin Erenkrantz wrote: I don't understand the purpose of serving incomplete files from a cache. Can you please elaborate on what you think mod_cache should do? -- justin Since the early days of mod_proxy, there has been a race condition in the caching code which has been carried over to mod_cache. After an URL has been invalidated, and before the new version of that URL has been downloaded completely from the backend server, any attempts by other clients to fetch the same URL are passed to the backend server directly. This results in the load spike on the backend server briefly while the replacement cache file is downloaded. If mod_cache was taught to serve a being-cached URL directly from the cache (shadowing the real download), there would be no need for parallel connections to the backend server while the file is being cached, and no load spike. Regards, Graham --
mod_proxy and friends, FIX_15207
Hi, The last couple of weeks I've had to dive into mod_proxy. I'd like to know what all the #ifdef FIX_15207 lines are all about in mod_proxy.c. Keeping the #define breaks the crap out of interaction with mod_rewrite for instance. Furthermore the documentation of mod_proxy* explains a lot of options that are not supported (anymore). Like ProxyPass ! for instance. The other thing is Proxy /location opt1=1 opt2=2 A side remark: mod_proxy_ajp doesn't follow our coding style rules. I know, if I have an itch, I should scratch it. However, I remember that a lot effort went into getting mod_proxy ready for 2.0 (that is, debugged on 2.0). I wouldn't want to get in the same situation for 2.2. Sander
RE: mod_proxy and friends, FIX_15207
From: Jim Jagielski [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 01, 2005 8:03 PM It's been on my table to attack the FIX_15207 fooishness, but neither keeping the define nor commenting it out results in expected, correct behavior :(... For my specific use case (mod_rewrite, mod_proxy_ajp, mod_cache) commenting it out did the trick. What are you running into? Might be an idea to create a list of things that work/don't work and thus need work? Sander
RE: Time for 2.0.53?
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED] Sent: Monday, January 31, 2005 10:19 PM Any opposition to doing a tag and roll of 2.0.53 soon? Nope. (Yes, I volunteer to be RM.) Thanks Justin. How about targetting next Tuesday (2/8) for 2.0.53? I can lay down the candidate tarball on Friday morning, so whatever backports are merged by then make it. =) I wouldn't pin yourself to a release date too much. Just start the TR and when we're satisfied with it, release. Do we want closure on Jeff's proxy chunking patch for 2.0.53? It's not a showstopper IMO. -- justin Sander
RE: Working on some load balancing methods
From: Jim Jagielski [mailto:[EMAIL PROTECTED] Sent: Friday, January 07, 2005 8:52 PM To: dev@httpd.apache.org Subject: Working on some load balancing methods I'm currently working on code that extended the lb method within the 2.1/2.2 proxy from what is basically a weighted request count to also be a weighted traffic count (as measured by bytes transferred) and a weighted load count (as measured by response time). The former is further along and the methods will be selectable at runtime... This is definitely a scratch I'm itching, I'm sure you are not the only one with that itch. but before I spend too much (additional) time on it, I'd like some feedback on whether the concept is one we can all get behind. FWIW, I like it. I am also toying with the idea of supporting a CPU load method when the origin servers are Apache via a custom response header... +1! Sander
[NOTICE] CVS to SVN migration complete
Hi everyone, The CVS to SVN conversion of the Apache HTTP Server projects is complete. To check out your project: apache 1.3: $ svn co http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x \ apache-1.3 httpd 2.0: $ svn co http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x \ httpd-2.0 httpd 2.1: $ svn co http://svn.apache.org/repos/asf/httpd/httpd/trunk \ httpd-2.1 httpd-test: $ svn co http://svn.apache.org/repos/asf/httpd/test/trunk \ httpd-test apreq: $ svn co http://svn.apache.org/repos/asf/httpd/apreq/branches/1.x \ apreq apreq-2: $ svn co http://svn.apache.org/repos/asf/httpd/apreq/trunk \ apreq-2 mod_python: $ svn co http://svn.apache.org/repos/asf/httpd/mod_python/trunk \ mod_python mod_mbox: $ svn co http://svn.apache.org/repos/asf/httpd/mod_mbox/trunk \ mod_mbox mod_pop3: $ svn co http://svn.apache.org/repos/asf/httpd/mod_pop3/trunk \ mod_pop3 httpd site: $ svn co http://svn.apache.org/repos/asf/httpd/site/trunk \ httpd-site Note that if you are a committer, you want to check out using https:// instead of http://. For further instructions on how to use SVN, I'll happily refer to: http://www.apache.org/dev/version-control.html Also note that there is one portion missing, which is the 1.3 documentation. We'll try to get around that ASAP. Once again, thanks for all your patience. I hope you feel it was worth the wait, Sander
CVS to SVN conversion
Hi again, The actual load seems to be working now (save the documentation...). Given that this wasn't a smooth ride, we've loaded things in the test repository. Please take a look at it: http://svn.apache.org/repos/test/httpd/ If noone raises any issues we'll load it in the main repository in 36 hours. Sander
[NOTICE] CVS to SVN migration complete
Hi everyone, The CVS to SVN conversion of the Apache HTTP Server projects is complete. To check out your project: apache 1.3: $ svn co http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x \ apache-1.3 httpd 2.0: $ svn co http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x \ httpd-2.0 httpd 2.1: $ svn co http://svn.apache.org/repos/asf/httpd/httpd/trunk \ httpd-2.1 httpd-test: $ svn co http://svn.apache.org/repos/asf/httpd/test/trunk \ httpd-test apreq: $ svn co http://svn.apache.org/repos/asf/httpd/apreq/branches/1.x \ apreq apreq-2: $ svn co http://svn.apache.org/repos/asf/httpd/apreq/trunk \ apreq-2 mod_python: $ svn co http://svn.apache.org/repos/asf/httpd/mod_python/trunk \ mod_python mod_mbox: $ svn co http://svn.apache.org/repos/asf/httpd/mod_mbox/trunk \ mod_mbox mod_pop3: $ svn co http://svn.apache.org/repos/asf/httpd/mod_pop3/trunk \ mod_pop3 httpd site: $ svn co http://svn.apache.org/repos/asf/httpd/site/trunk \ httpd-site Note that if you are a committer, you want to check out using https:// instead of http://. For further instructions on how to use SVN, I'll happily refer to: http://www.apache.org/dev/version-control.html Also note that there is one portion missing, which is the 1.3 documentation. We'll try to get around that ASAP. Once again, thanks for all your patience. I hope you feel it was worth the wait, Sander
Re: CVS to SVN conversion
On Fri, 2004-11-19 at 11:04, Justin Erenkrantz wrote: --On Friday, November 19, 2004 7:57 PM +0100 André Malo [EMAIL PROTECTED] wrote: Looks basically fine. I'm wondering a bit about the tags directory, especially the 1.3 subdir. Is it necessary, is there something broken? Just to be clear, Sander's email that you are replying to was an artifact of the busted network at Alexis Park. Indeed, others will find they have received 'out-of-date' mail from me as well. The conversion is now complete and live at: http://svn.apache.org/repos/asf/httpd/ Sander should be following up with detailed instructions soon-ish. But, alas, I think he fell asleep at the keyboard once again this morning. ;-) *blush* The instructions ended up not to be so detailed, but hey :) Regarding the tags/1.3 subdir, those are the complete tags for the 1.3 series. Our conversion got royally messed up due to the docs files as they contain overlapping tags with the 1.3 repository. So, I've cleared out most of the bogus tags in the tags/ directory and I need to move all of the 'real' 1.3 tags into the tags/ dir. Thanks again Justin, Sander
SVN usage, log message policy
Hi guys, Now that we are using SVN, would we want to adopt a guideline for log messages. The SVN project itself uses a standard format for all their log messages and I must say that it has helped me tremendously when doing reviews. See http://svn.collab.net/repos/svn/HACKING for details (look for Writing log messages). I reckomend reading the entire document, since I think it has more useful ideas than just providing a guideline on log messages. Sander PS. I'll most likely be offline for the entire upcoming week, in case you wonder why I don't contribute to the resulting thread.
CVS to SVN migration
Hi all, Justin and I have been up all night again working on the httpd-* conversion. We've come to about 10% of loading the final dumpfile and then we run into some issues. We think we've sorted that out now and are restarting the load (in a test repos). Loading takes quite a long time, so we've started it again and are of to bed. We'll check on it in the morning... oh wait... make that around lunch. The issues we are seeing are related to our f#$%ed up history of our CVS files. The copies of the files from one directory to another leads to duplication, and thus failures. We have been working on this intensively, with an earlier date of completion in mind. Unfortunately we can't meet that. This however doesn't mean that CVS will be reopened. Thanks for your patience, Sander 'no sleep for me :/' Striker
Re: [NOTICE] Subversion conversion
On Tue, 2004-11-16 at 07:03, Bill Stoddard wrote: Sander Striker wrote: Hi, I'm finally taking care of the conversion of httpd-* to SVN. I'll follow up with instructions on how to pull new workingcopies, etc etc. I'm looking for volunteers to actually write a page for developers on where to get SVN and how to check out the sources from the SVN repository. I'm shooting for being done with it all by tomorrow night. Sander Did this happen? Some irresponsible partying is delaying the process a bit... Sander
Re: [NOTICE] Subversion conversion
On Tue, 2004-11-16 at 09:34, Sander Striker wrote: On Tue, 2004-11-16 at 07:03, Bill Stoddard wrote: Sander Striker wrote: Did this happen? Some irresponsible partying is delaying the process a bit... To clarify: I was planning on moving forward yesterday after The Incredibles. I got about 80% through. I'll continue after breakfast. Apologies for the holdup. I promise it'll be worth it though. Sander
[NOTICE] Subversion conversion
Hi, I'm finally taking care of the conversion of httpd-* to SVN. I'll follow up with instructions on how to pull new workingcopies, etc etc. I'm looking for volunteers to actually write a page for developers on where to get SVN and how to check out the sources from the SVN repository. I'm shooting for being done with it all by tomorrow night. Sander
[PATCH] Site, ApacheCon 2004
Hi, I did some mods to the site, highlighting all sessions about httpd, but frankly, it looks totally messy. If someone with a bright idea on how to make this look better wants to take a stab at it, that would be much appreciated. Sander site.ac2004.patch Description: Binary data
RE: Bye bye welcome page
On Thu, 2004-10-07 at 12:08, John Rowe wrote: If I was a newbie, and I saw a page that says `it worked`, my immediate reaction would be `what worked?` and I would start asking the exact questions we`re trying to stop people from asking. We can always go with simply displaying a meaningless word like 'Waboozle'. And so the madness begins again.. [...] I do hope everyone realizes I was kidding. The only thing we have to do is agree on a concise and clear message. I don't think it is we are likely to reach concensus on proze like the welcome page. Other than lazy concensus that is. FWIW, I'm fine with Joshua's suggestion. Sander
RE: Bye bye welcome page
-Original Message- From: Graham Leggett [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 8:36 PM To: [EMAIL PROTECTED] Subject: Re: Bye bye welcome page Joshua Slive wrote: My opinion is that the shorter message is better because, by the fact that it gives no information at all, it is less likely to be misinterpreted to mean something that the website owner doesn't intend. I won't object if someone wants to put another piece of text there, as long as it doesn't start us back on the same road we left 5+ years ago with this page. In that case why not just have the default page be an empty drectory listing? If I was a newbie, and I saw a page that says `it worked`, my immediate reaction would be `what worked?` and I would start asking the exact questions we`re trying to stop people from asking. We can always go with simply displaying a meaningless word like 'Waboozle'. Sander
Re: Moving httpd-2.0 to Subversion
On Mon, 2004-09-27 at 06:13, Joe Schaefer wrote: Sander Striker [EMAIL PROTECTED] writes: Probably not worth it given all of the parallel development. Well, I'd rather see us using something like this: httpd/ apreq/ trunk/ branches/ tags/ +1, with more details: httpd-apreq current cvs should probably go to apreq/branches/1.3 and httpd-apreq-2 cvs can go to apreq/trunk. *nod* Also, will the apreq commit emails still be sent to apreq-cvs@, or will every commit to the httpd repository have to go to a common commit list? We can configure the mailer however we like (within boundaries of reason ofcourse :). Sander
RE: [OT] Developer lists and Reply-To header
From: Jeff Trawick [mailto:[EMAIL PROTECTED] Sent: Thursday, September 23, 2004 2:50 PM On Thu, 23 Sep 2004 13:20:49 +0200, Mladen Turk [EMAIL PROTECTED] wrote: Hi, Is there any reason why apr, apr-util, httpd mailing lists have Reply-To header set to the sender and not to the list itself. the reason NOT to do it is that it is unintuitive to most people (okay, just me and Mladen) and causes needless vigilance to fix the To/Cc (but [EMAIL PROTECTED] acts in the more intuitive manner, setting Reply-To to the mailing list) Which I would have no issue with fixing... :^) Sander
Re: Moving httpd-2.0 to Subversion
From: Paul Querna [EMAIL PROTECTED] Sent: Friday, September 17, 2004 7:34 AM Hi, The Original Proposal was in March of this year: http://marc.theaimsgroup.com/?t=10791831443r=2w=2 +1 Votes: Tom May Justin Erenkrantz Andr Malo Erik Abele Jim Jagielski Bill Stoddard Joe Orton I can't believe I am not in this list... -1 Votes: Aaron Bannert Aaron said: This will, at least for now, raise the bar to entry for contributors. [...] What are the barriers to moving to Subversion? Other than making the actual decision? None. I believe we might as well do it now, before we start on a new stable branch (2.2). Time for another Vote? Here's my +1. I should note though that we voted to move 1.3 ages ago, and I managed to drop the ball on that one. When I finally got around to processing the 1.3 converted CVS repository, Fitz had removed it from his homedir. cvs2svn has seen a release as well, and has been improved a lot since march. Infrastructure is now totally able to run the cvs2svn conversion itself. I fully intent to start on the 1.3 conversion tonight; this time without dropping the ball... Sander
[VOTE] Apache HTTP Server 2.0.51
Hi, I've put the tarballs for 2.0.51 up at http://httpd.apache.org/dev/dist/. Please test and vote, Sander
Re: [VOTE] Apache HTTP Server 2.0.51
From: Sander Striker [EMAIL PROTECTED] Sent: Wednesday, September 15, 2004 4:49 PM Thanks. I've moved the tarballs to the distribution area. Could someone please take care of the httpd.apache.org site? I'm in a bit of a bind currently (for at least another 1-2 hours). Sander
