Re: [VOTE] Release httpd-2.0.53
måndag 07 februari 2005 06.38 skrev Justin Erenkrantz: On Sun, Feb 06, 2005 at 09:39:47PM +0100, Oden Eriksson wrote: I'd say +1, but I think I have no rights to vote. It seems to work just fine on several Mandrakelinux 10.0 production boxes and also on Cooker. Even if you aren't a committer, you can always cast a vote. Everyone's input is valuable. Yes, if you aren't a committer, your vote doesn't count towards the 3 +1s required for a release, but that shouldn't stop you from voting. It looks like we've received enough +1s that I'm going to move 2.0.53 into the mirrors now. Sometime tomorrow, I will update the website and send the announcement. Thanks! -- justin Hey!, that tarball named httpd-2.0.53.tar.gz is really rc1. -- Regards // Oden Eriksson
Re: [VOTE] Release httpd-2.0.53
A little late, but for the record: +1 (tested on OS X/Darwin and Sol8) On Feb 5, 2005, at 7:08 PM, Jeff Trawick wrote: On Fri, 04 Feb 2005 15:00:58 -0800, Justin Erenkrantz [EMAIL PROTECTED] wrote: Tarballs for 2.0.53 are available and at: http://www.apache.org/~jerenkrantz/httpd-2.0.53/ Once we receive 3 +1s (and no -1s, hopefully!), I'll move it over to the mirrors. I then hope to be able to do the announcement and email some time on Monday. +1 (tested with worker MPM on AIX 5.3) it looks like we still have some \n chars passed to ap_log_error(), but that's no regression since 2.0.52... [Sat Feb 05 18:59:23 2005] [alert] Child 12332 returned a Fatal error...\nApache is exiting! (I had Group directive set to bad value, causing this failure) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: [VOTE] Release httpd-2.0.53
måndag 07 februari 2005 12.36 skrev Oden Eriksson: måndag 07 februari 2005 06.38 skrev Justin Erenkrantz: On Sun, Feb 06, 2005 at 09:39:47PM +0100, Oden Eriksson wrote: I'd say +1, but I think I have no rights to vote. It seems to work just fine on several Mandrakelinux 10.0 production boxes and also on Cooker. Even if you aren't a committer, you can always cast a vote. Everyone's input is valuable. Yes, if you aren't a committer, your vote doesn't count towards the 3 +1s required for a release, but that shouldn't stop you from voting. It looks like we've received enough +1s that I'm going to move 2.0.53 into the mirrors now. Sometime tomorrow, I will update the website and send the announcement. Thanks! -- justin Hey!, that tarball named httpd-2.0.53.tar.gz is really rc1. I meant if you unpack the tar ball, the root directory name is httpd-2.0.53-rc1 and not httpd-2.0.53. Does that matter? -- Regards // Oden Eriksson
Re: [VOTE] Release httpd-2.0.53
söndag 06 februari 2005 19.57 skrev Paul Querna: Justin Erenkrantz wrote: Tarballs for 2.0.53 are available and at: http://www.apache.org/~jerenkrantz/httpd-2.0.53/ Oh!, I just noticed this using the tar balls from http://www.apache.org/~jerenkrantz/0.9.6/ (same code as the bundled one) /bin/sh /home/oden/RPM/BUILD/apr-0.9.6/libtool --silent --mode=compile gcc -pthread -O2 -fomit-frame-pointer -pipe -march=i586 -mtune=pentiumpro -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I../../include -I../../include/arch/unix -c threadpriv.c touch threadpriv.lo thread.c:104: error: redefinition of 'apr_threadattr_stacksize_set' thread.c:88: error: previous definition of 'apr_threadattr_stacksize_set' was here make[2]: *** [thread.lo] Error 1 -- Regards // Oden Eriksson
Re: [VOTE] Release httpd-2.0.53
On Mon, 7 Feb 2005 14:34:16 +0100, Oden Eriksson [EMAIL PROTECTED] wrote: Oh!, I just noticed this using the tar balls from http://www.apache.org/~jerenkrantz/0.9.6/ (same code as the bundled one) /bin/sh /home/oden/RPM/BUILD/apr-0.9.6/libtool --silent --mode=compile gcc -pthread -O2 -fomit-frame-pointer -pipe -march=i586 -mtune=pentiumpro -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I../../include -I../../include/arch/unix -c threadpriv.c touch threadpriv.lo thread.c:104: error: redefinition of 'apr_threadattr_stacksize_set' thread.c:88: error: previous definition of 'apr_threadattr_stacksize_set' was here Can you figure out why gcc complains about thread.c when it has been told to compile threadpriv.c? Was that simply a cut and paste issue? Also, this is my line 104 in thread.c: apr_thread_t *thread = (apr_thread_t*)opaque; What do you have?
Re: [VOTE] Release httpd-2.0.53
måndag 07 februari 2005 14.42 skrev Jeff Trawick: On Mon, 7 Feb 2005 14:34:16 +0100, Oden Eriksson [EMAIL PROTECTED] wrote: Oh!, I just noticed this using the tar balls from http://www.apache.org/~jerenkrantz/0.9.6/ (same code as the bundled one) /bin/sh /home/oden/RPM/BUILD/apr-0.9.6/libtool --silent --mode=compile gcc -pthread -O2 -fomit-frame-pointer -pipe -march=i586 -mtune=pentiumpro -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I../../include -I../../include/arch/unix -c threadpriv.c touch threadpriv.lo thread.c:104: error: redefinition of 'apr_threadattr_stacksize_set' thread.c:88: error: previous definition of 'apr_threadattr_stacksize_set' was here Can you figure out why gcc complains about thread.c when it has been told to compile threadpriv.c? Was that simply a cut and paste issue? Also, this is my line 104 in thread.c: apr_thread_t *thread = (apr_thread_t*)opaque; What do you have? Oops. It seems I forgot to nuke one of the patches. Sorry for the noise. -- Regards // Oden Eriksson
Re: [VOTE] Release httpd-2.0.53
On Mon, Feb 07, 2005 at 02:28:17PM +0100, Oden Eriksson wrote: I meant if you unpack the tar ball, the root directory name is httpd-2.0.53-rc1 and not httpd-2.0.53. Does that matter? Ah, darn. I'll fix it before I make it public. -- justin
Re: [VOTE] Release httpd-2.0.53
måndag 07 februari 2005 16.29 skrev Justin Erenkrantz: On Mon, Feb 07, 2005 at 02:28:17PM +0100, Oden Eriksson wrote: I meant if you unpack the tar ball, the root directory name is httpd-2.0.53-rc1 and not httpd-2.0.53. Does that matter? Ah, darn. I'll fix it before I make it public. -- justin Cool. Thanks. -- Regards // Oden Eriksson
Re: [VOTE] Release httpd-2.0.53
At 11:38 PM 2/6/2005, Justin Erenkrantz wrote: It looks like we've received enough +1s that I'm going to move 2.0.53 into the mirrors now. Sometime tomorrow, I will update the website and send the announcement. Question - did infra already put this to the fire under www.apache.org? Given all the quirks we'd seen keeping viewsvn stable, a pass on svn.apache.org would be extra reassuring. Bill
Re: [VOTE] Release httpd-2.0.53
--On Monday, February 7, 2005 11:08 AM -0600 Jess Holle [EMAIL PROTECTED] wrote: It appears that 2.0.53 does not include the LDAP socket timeout configuration patch. Is this true? If so, is there a 2.0.x-ready patch for this? We'll be building 2.0.53 binaries shortly and I'm interested in this patch whether it made it into 2.0.53 or not. I think you are talking about: *) util_ldap: Add the directive LDAPConnectionTimeout to control the socket timeout value when binding to an LDAP server svn rev 126565 +1: bnicholes Since it only received one vote, I couldn't include it in 2.0.53. And, I certainly don't consider it a showstopper. -- justin
Re: [VOTE] Release httpd-2.0.53
At 11:11 AM 2/7/2005, Justin Erenkrantz wrote: --On Monday, February 7, 2005 9:55 AM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Question - did infra already put this to the fire under www.apache.org? Given all the quirks we'd seen keeping viewsvn stable, a pass on svn.apache.org would be extra reassuring. Not yet: I'll leave it to Greg and/or Jeff to upgrade the www instance if they so desire. Since this is the stable release, and few of us are truly putting httpd to the fire (so to speak) in the real world, I'm never comfortable calling it baked until we've performed this stress test. IIUC -all- of our recent (successful) releases passed this stress test, chewing our own dog food, before releasing 2.0-stable. And, svn.apache.org uses unstable (i.e. 2.1.x). httpd isn't at fault for the SVN problems: it has to do with ViewCVS and Subversion. -- justin Oh - knew that. My point was, it's a different sort of httpd instance, and one which would be good to vet under load before blessing 2.0.53. If there is a regression, I'd hate to see it have an interaction with svn. Bill
mod_cache and Etag headers
Hi,
we are trying to use mod_proxy/mod_cache as a `reverse proxy' in front
of our webserver. In our configuration, we would like Apache to cache
all responses from our server, but revalidate them for every new
request. To do that, we are sending Etag headers and force revalidation
using Cache-Control: max-age=0,must-revalidate.
This mostly works, but does not perform caching the way we would like it
to, because the Etag headers are not sent to our server when mod_cache
tries to revalidate it cache file.
We would like the following to happen:
- When a client connects for the first time, Apache asks our server
(code 200), caches the response (including the Etag header) and sends it
to the server (code 200), caching the Etag header received.
(This works!)
- When a client (which keeps its own cache) connects for the second
time, Apache finds the cached response, revalidates with our
server, receives code 304 and sends it back to the client.
(This happens to work, because the client itself sends along
If-None-Match: our-etag in this case.)
- When a different client (which does not have our Etag in its cache)
connects, Apache should find the cached response for the URL, revalidate
with our server, receive code 304 from our server and send
the cached response to the client (code 200).
The last situation is what does not work -- our server does not receive
an If-None-Match header from Apache in this case.
Questions:
0. Is this supposed to work at all?
1. Looking briefly at the mod_cache source code, there appear to be
cases dealing with this. In cache_select_url(), info-etag is
looked at to decide whether If-None-Match should be inserted into
the request.
However, info-etag is null at this point.
If I hack this check so that the etag header is looked up from the
cached response (see patch below), things work better and our
server replies with 304.
However,
2. Apache then sends the 304 response along to the client, although the
client did not send a conditional request at all and needs the full
cached response.
There is a check in cache_save_filter() (Were we initially a
conditional request?), but that check is not reached in this
situation.
Thanks for any help,
David
--- httpd-2.1.2-alpha-orig/modules/cache/cache_storage.c2004-11-27
20:06:48.0 +0100
+++ httpd-2.1.2-alpha/modules/cache/cache_storage.c 2005-02-07
18:14:09.0 +0100
@@ -255,6 +255,8 @@
/* Make response into a conditional */
/* FIXME: What if the request is already conditional? */
+if (info)
+info-etag = apr_table_get(h-resp_hdrs, etag);
if (info info-etag) {
/* if we have a cached etag */
cache-stale_headers = apr_table_copy(r-pool,
LDAP socket timeout patch (was:Re: [VOTE] Release httpd-2.0.53)
I have a 2.0 compatible patch just about ready to go. Once I get it cleaned up, I will post it as a 2.0.53 patch in the patches directory off of the download page. Brad [EMAIL PROTECTED] Monday, February 07, 2005 10:08:29 AM It appears that 2.0.53 does not include the LDAP socket timeout configuration patch. Is this true? If so, is there a 2.0.x-ready patch for this? We'll be building 2.0.53 binaries shortly and I'm interested in this patch whether it made it into 2.0.53 or not. -- Jess Holle
Re: LDAP socket timeout patch (was:Re: [VOTE] Release httpd-2.0.53)
Thank you! -- Jess Holle Brad Nicholes wrote: I have a 2.0 compatible patch just about ready to go. Once I get it cleaned up, I will post it as a 2.0.53 patch in the patches directory off of the download page. Brad [EMAIL PROTECTED] Monday, February 07, 2005 10:08:29 AM It appears that 2.0.53 does not include the LDAP socket timeout configuration patch. Is this true? If so, is there a 2.0.x-ready patch for this? We'll be building 2.0.53 binaries shortly and I'm interested in this patch whether it made it into 2.0.53 or not. -- Jess Holle
Re: [VOTE] Release httpd-2.0.53
William A. Rowe, Jr. wrote: Question - did infra already put this to the fire under www.apache.org? Given all the quirks we'd seen keeping viewsvn stable, a pass on svn.apache.org would be extra reassuring. I'm working on it. log replay is not behaving at the moment but it looks more like a client problem than a server problem. I'm tempted to just switch production over but would feel better if my usual tests would behave. Manual tests are all fine. Greg
2.0.53 update was Re: [VOTE] Release httpd-2.0.53
--On Monday, February 7, 2005 1:50 PM -0500 Greg Ames [EMAIL PROTECTED] wrote: I'm working on it. log replay is not behaving at the moment but it looks more like a client problem than a server problem. I'm tempted to just switch production over but would feel better if my usual tests would behave. Manual tests are all fine. Excellent. I've now checked in a draft of the Announcement to httpd/dist/. I'll give the translators a few hours to translate it. I don't think the translation should be a big deal. (Mainly: 2.0.52-2.0.53 and axe the security portion from 2.0.52's announcement.) I plan on updating the website to announce 2.0.53 later this afternoon (say 4pm Pacific). And, then, I plan on sending the email first thing tomorrow morning (~9am Pacific). Hopefully, we should be able to get some positive feedback from minotaur by then. =) Thanks! -- justin
www.apache.org is running httpd-2.0.53-rc1
It's been up 2 1/2 hours and looks fine to me. Let us know if you spot a problem. btw, I would appreciate being copied directly on related emails. My apache.org mailing list posts are way behind. Thanks, Greg
Re: mod_cache and Etag headers
--On Monday, February 7, 2005 6:45 PM +0100 David Lichteblau [EMAIL PROTECTED] wrote: we are trying to use mod_proxy/mod_cache as a `reverse proxy' in front of our webserver. In our configuration, we would like Apache to cache all responses from our server, but revalidate them for every new request. To do that, we are sending Etag headers and force revalidation using Cache-Control: max-age=0,must-revalidate. First off, what version are you planning to use? httpd 2.0.53 has a bunch of important fixes for the revalidation functionality. The httpd trunk in SVN (2.1.3-dev as of right now) has a lot more fixes that are probably going to be important to seeing this work as a whole. Your patch below is against 2.1.2-alpha, so that partially answers that question. 2.1.2-alpha should contains most of the recent fixes, but you should try to follow trunk for now. (Once 2.0.53 is out, I hope to issue another 2.1.alpha release soon.) - When a client connects for the first time, Apache asks our server (code 200), caches the response (including the Etag header) and sends it to the server (code 200), caching the Etag header received. (This works!) - When a client (which keeps its own cache) connects for the second time, Apache finds the cached response, revalidates with our server, receives code 304 and sends it back to the client. (This happens to work, because the client itself sends along If-None-Match: our-etag in this case.) - When a different client (which does not have our Etag in its cache) connects, Apache should find the cached response for the URL, revalidate with our server, receive code 304 from our server and send the cached response to the client (code 200). The last situation is what does not work -- our server does not receive an If-None-Match header from Apache in this case. Has it passed the age check? Oh, wait, your server is setting 'max-age=0,must-revalidate'. Okay, so, you'd expect to see that every time. Questions: 0. Is this supposed to work at all? Yes. Whether it does or not is up for discussion. =) mod_cache has recently undergone a lot of work to make it better, but there might be some corner cases that aren't quite right yet. 1. Looking briefly at the mod_cache source code, there appear to be cases dealing with this. In cache_select_url(), info-etag is looked at to decide whether If-None-Match should be inserted into the request. However, info-etag is null at this point. If I hack this check so that the etag header is looked up from the cached response (see patch below), things work better and our server replies with 304. Hmm. That shouldn't be necessary. The recall_headers function should be loading this value. Which cache provider are you using? mod_disk_cache or mod_mem_cache? I can only attest that mod_disk_cache works - I don't know anything about mod_mem_cache. However, 2. Apache then sends the 304 response along to the client, although the client did not send a conditional request at all and needs the full cached response. There is a check in cache_save_filter() (Were we initially a conditional request?), but that check is not reached in this situation. Again, it should be. Okay, I just tried a reproduction of what I think you are doing and I found two obscenely small one-line bugs. I just committed fixes in r151815 and r151816. Can you please try trunk? I expect it might work now. =) Thanks! -- justin
