Re: Apache 2.0.40 (prerelease) is available for testing
On Tue, Jul 16, 2002 at 08:49:29PM -0500, William A. Rowe, Jr. wrote: > However, we didn't destroy ap_get_client_block until May 30, 2002. If you could please clarify what you mean by 'destroy ap_get_client_block,' that would be greatly appreciated. All that commit should have done was reimplement it not break it. If there was any breakage, it was certainly unintentional. -- justin
Re: [PATCH] Patch to compile apache-1.3.20+ on LynxOS-3.0.1
Hi, I have LynxOS-3.0.1 and if you try to use find with -depth obtain a syntax error! >find . -depth -print find: syntax error at -depth Maybe it is possible (I don't try to do this) to install the GNU findutils and this can resolve the problem but the find distributed with this version of the LynxOS doesn't support -depth option. Bye, Fulvio Bille` Jim Jagielski wrote: > Not sure if they went through, or if I just missed the reply. > > These patches look good but I have a question about this: > > At 1:51 PM +0200 7/10/02, Fulvio Bille` wrote: > >diff -ruN ./src/helpers/mkshadow.sh > >../apache_1.3.26-patched/src/helpers/mkshadow.sh > >--- ./src/helpers/mkshadow.sh Tue Jun 29 15:43:15 1999 > >+++ ../apache_1.3.26-patched/src/helpers/mkshadow.sh Fri Jul 5 14:11:19 > > > >2002 > >@@ -65,7 +65,7 @@ > > > > # fill directory tree with symlinks to files > > FILES="`cd $src; \ > >-find . -depth -print |\ > >+find . -print |\ > > sed -e '/\.o$/d' \ > > -e '/\.a$/d' \ > > -e '/\.so$/d' \ > > Why the change? Does LynxOS-3.0.1 find not support -depth? > -- > === >Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ > "A society that will trade a little liberty for a little order > will lose both and deserve neither" - T.Jefferson
Re: Apache 2.0.40 (prerelease) is available for testing
At 07:09 PM 7/16/2002, Justin Erenkrantz wrote: >On Tue, Jul 16, 2002 at 06:33:08PM -0500, William A. Rowe, Jr. wrote: > > Unlikely. I recently discovered that the input filtering changes have > > completely corrupted mod_isapi.c. > > > > Since r->remaining is entirely invalid now, that code [conventional, > > safe and traditional module authoring style] is totally borked. > >By my count, r->remaining has been 'invalid' since gregames's >commit to http_protocol.c revision 1.376 (November 7, 2001). > >http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/http/http_protocol.c.diff?r1=1.375&r2=1.376 > >So, this has been the case for every httpd-2.0 GA release. -- justin However, we didn't destroy ap_get_client_block until May 30, 2002.
Re: [PATCH] 64bit compiler issues
On Tue, Jul 16, 2002 at 10:31:46AM -0500, William A. Rowe, Jr. wrote: > At 07:23 PM 7/15/2002, Ryan Bloom wrote: > > >We could force the size, by using apr_int32_t. The problem that he is There is no need to force the size. The value is a simple integer. There is no need to make it a long, and that integer will always be castable into a void*, and then back (when we pull it out of the hash table). I see no purpose in the patch's casting to a long. What exactly is that solving? We need a response from Peter. > >having, is that pointers on _most_ 64-bit machines (Windows is a notable > >exception, there may be others), are 64-bits long. But we are using > >int's, which are 32-bits for the pointers. We have the added problem > >that throughout the code, we pass in integers for void *'s. :-( No. You've got that backwards. We're putting integers into points, and then going back to integers. We are *not* attemping to stuff a pointer into an integer. >... > When we mean a void*, we need to spell out void*. If we need to > pass it through an integer, prove it, and we will consider an We aren't. Ryan set you off on a red herring. * mod_dav's namespace indexes are integers * we stuff those into a hash table * we extract them from a hash table Peter's patch changes the indexes to longs. Why? Cheers, -g -- Greg Stein, http://www.lyra.org/
environment in mod_ext_filter
Hi, In modules/experimental/mod_ext_filter.c there's the following: rc = apr_proc_create(ctx->proc, ctx->filter->command, (const char * const *)ctx->filter->args, NULL, /* environment */ ctx->procattr, ctx->p); Is there a reason why the environment is null? I was able to hack in the env in a few simples lines. Am I missing something? Is there a reason I shouldn't submit this patch? Thanx, Craig
cache_pqueue.[ch]
Hey guys... I just committed some optimizations to cache_pqueue that should help a good deal. I'm reasonably confident in the changes (and I ran it through a test program to be sure) ... but this is just a "heads up" since I don't actually have a mod_cache setup to test it with. --Cliff
Re: Apache 2.0.40 (prerelease) is available for testing
On Tue, Jul 16, 2002 at 06:33:08PM -0500, William A. Rowe, Jr. wrote: > Unlikely. I recently discovered that the input filtering changes have > completely corrupted mod_isapi.c. > > Since r->remaining is entirely invalid now, that code [conventional, > safe and traditional module authoring style] is totally borked. By my count, r->remaining has been 'invalid' since gregames's commit to http_protocol.c revision 1.376 (November 7, 2001). http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/http/http_protocol.c.diff?r1=1.375&r2=1.376 So, this has been the case for every httpd-2.0 GA release. -- justin
Re: Apache 2.0.40 (prerelease) is available for testing
Unlikely. I recently discovered that the input filtering changes have completely corrupted mod_isapi.c. Since r->remaining is entirely invalid now, that code [conventional, safe and traditional module authoring style] is totally borked. Looks like a couple days before it can be fixed. Bill At 04:47 PM 7/16/2002, Ian Holsman wrote: >in http://httpd.apache.org/dev/dist/ >if all goes well this will be the '2.0.40' release > >Thanks >Ian
Re: [PATCH] make pathnames in ssl-std.conf configurable
On Mon, Jul 15, 2002 at 06:57:05PM +0200, Peter Poeml wrote: > Hi, > > I'd like to propose to create ssl-std.conf from ssl-std.conf.in, just as > it is done with httpd-std.conf.in. Then, the log file paths could be > substituted in the same flexible way. > > Currently, of patching / hand editing is necessary for adjustments in > that file. In the past, we have been relucant to have SSL work for people out-of-the-box. I don't have a problem with adding this, but I would like some buy-in from others before committing this. I think we've discussed this before and the consensus was not to subsitute values for ssl-std.conf. -- justin
Re: [PATCH] autoconf macros: quote macro names
On Mon, Jul 15, 2002 at 06:01:10PM +0200, Peter Poeml wrote: > Hi, > > in the autoconf macro definitions of acinclude.m4, the macro names are > not quoted as suggested in the autoconf documentation for AC_DEFUN: > > > [...] >Be sure to properly quote both the MACRO-BODY _and_ the MACRO-NAME > to avoid any problems if the macro happens to have been previously > defined. > [...] > > > The missing quotes actually lead to problems when running autoreconf > with recent autoconf versions. What versions of autoconf have this problem? -- justin
Apache 2.0.40 (prerelease) is available for testing
in http://httpd.apache.org/dev/dist/ if all goes well this will be the '2.0.40' release Thanks Ian
Re: [PATCH] mod_rewrite and cookie setting
On Tue, Jul 16, 2002 at 10:26:49AM -0700, Ian Holsman wrote: > Adam Sussman wrote: > > The new cookie setting feature of mod_rewrite adds the Set-Cookie header > > to r->headers_out. Shouldn't this be r->err_headers_out instead? > > > > The error headers are always present whereas the the normal headers do not > > appear under error conditions. In applications where I have an apache > > module setting cookies, I have always found that setting err_headers_out > > gives me the complete coverage that I want. > > > > Thoughts? > yep.. a couple of them > the original patch has err_headers_out and it didn't work as we would > get multiple cookies back on a simple request on GET / on a standard > install. > hmm... I cannot reproduce this behaviour. So far as I can see, the only difference is whether or not the cookie header appears in non-200 reponses. Can you show me the configuration you used? -adam
Re: cvs commit: httpd-2.0 acinclude.m4 CHANGES
On Tue, Jul 16, 2002 at 11:42:13AM -0700, Ryan Bloom wrote: > That would only work if we looked in those variable for the files. But, > we don't, so we have to special case this stuff. We should re-write big > portions of the detection logic so that we don't have ANY hard-coded > paths, but I am not volunteering for that. True. I had planned on doing this before, but never got around to it. I did this for flood, so maybe I can just port it back over. -aaron
RE: cvs commit: httpd-2.0 acinclude.m4 CHANGES
> From: Aaron Bannert [mailto:[EMAIL PROTECTED]] > > > Look for OpenSSL libraries in /usr/lib64. > ... > > for p in $ap_ssltk_base/lib /usr/local/openssl/lib \ > > - /usr/local/ssl/lib /usr/local/lib /usr/lib /lib; do > > + /usr/local/ssl/lib /usr/local/lib /usr/lib /lib > /usr/lib64; do > > If we just told people to add the right include and lib paths to their > CPPFLAGS and LDFLAGS variables, then we wouldn't have to add any > special case directories to our autoconf routines... *sigh* That would only work if we looked in those variable for the files. But, we don't, so we have to special case this stuff. We should re-write big portions of the detection logic so that we don't have ANY hard-coded paths, but I am not volunteering for that. Ryan
Re: cvs commit: httpd-2.0 acinclude.m4 CHANGES
> Look for OpenSSL libraries in /usr/lib64. ... > for p in $ap_ssltk_base/lib /usr/local/openssl/lib \ > - /usr/local/ssl/lib /usr/local/lib /usr/lib /lib; do > + /usr/local/ssl/lib /usr/local/lib /usr/lib /lib /usr/lib64; do If we just told people to add the right include and lib paths to their CPPFLAGS and LDFLAGS variables, then we wouldn't have to add any special case directories to our autoconf routines... *sigh* -aaron
Re: [PATCH] find SSL/TLS toolkit libraries on 64bit platforms
On Mon, Jul 15, 2002 at 02:50:35PM +0200, Peter Poeml wrote: > Hi, > > the attached patch adds /usr/lib64 to the list of directories to > look for SSL/TLS toolkit libraries. > > /usr/lib64 is the libdir on AMD x86_64 and other 64 bit platforms where > 32bit and 64bit libs can be installed side by side. > > The patch applies against 2.0.39 and the head branch. Committed. Thanks! -- justin
Re: [PATCH] update config.layout for SuSE distributions
On Mon, Jul 15, 2002 at 06:01:42PM +0200, Peter Poeml wrote: > Hi, > > attached patch, made for 2.0.39 and fitting into current cvs, updates > config.layout for the layout on our distribution. Committed. Thanks! -- justin
Re: apxs in 2.0.36
"Rob Emanuele" <[EMAIL PROTECTED]> writes: > I can't make apxs generate so's by default. It makes an lo > instead. look in the .libs that is created apxs -c mod_foo.c compile, creates shared object in .libs/ the name can vary between platforms apxs -i mod_foo.lainstall, figures out name of file in .libs/ to grab and install as mod_foo.so -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [PATCH] mod_rewrite and cookie setting
Adam Sussman wrote: > The new cookie setting feature of mod_rewrite adds the Set-Cookie header > to r->headers_out. Shouldn't this be r->err_headers_out instead? > > The error headers are always present whereas the the normal headers do not > appear under error conditions. In applications where I have an apache > module setting cookies, I have always found that setting err_headers_out > gives me the complete coverage that I want. > > Thoughts? yep.. a couple of them the original patch has err_headers_out and it didn't work as we would get multiple cookies back on a simple request on GET / on a standard install. > > -adam > > Attached is a patch to set err_headers_out instead: > > Index: mod_rewrite.c > === > RCS file: /home/cvspublic/httpd-2.0/modules/mappers/mod_rewrite.c,v > retrieving revision 1.124 > diff -u -r1.124 mod_rewrite.c > --- mod_rewrite.c 10 Jul 2002 06:01:10 - 1.124 > +++ mod_rewrite.c 16 Jul 2002 17:15:33 - > @@ -4162,12 +4162,7 @@ > : NULL, >NULL); > > - > -/* > - * XXX: should we add it to err_headers_out as well ? > - * if we do we need to be careful that only ONE gets sent out > - */ > -apr_table_add(r->headers_out, "Set-Cookie", cookie); > +apr_table_add(r->err_headers_out, "Set-Cookie", cookie); > rewritelog(r, 5, "setting cookie '%s' to '%s'", var, val); > } > } >
Re: cvs commit: httpd-2.0/support apachectl.in
On Tue, Jul 16, 2002 at 08:30:41AM -, [EMAIL PROTECTED] wrote: > martin 2002/07/16 01:30:41 > > Modified:support apachectl.in > Log: > If "@APACHECTL_ULIMIT@" is used in apachectl.in, then something must > replace it by a sensible (platform dependent?) value upon "make install". > Until that is done, $ULIMIT_MAX_FILES is set to the empty string > so that apachectl does not cause a subsequent error > @APACHECTL_ULIMIT@: not found This is replaced for me when I run configure, are you not using autoconf? In any case, if what is substituted for you right now doesn't work, we should fix it in autoconf, not remove the substitution from apachectl.in. -aaron
[PATCH] mod_rewrite and cookie setting
The new cookie setting feature of mod_rewrite adds the Set-Cookie header to r->headers_out. Shouldn't this be r->err_headers_out instead? The error headers are always present whereas the the normal headers do not appear under error conditions. In applications where I have an apache module setting cookies, I have always found that setting err_headers_out gives me the complete coverage that I want. Thoughts? -adam Attached is a patch to set err_headers_out instead: Index: mod_rewrite.c === RCS file: /home/cvspublic/httpd-2.0/modules/mappers/mod_rewrite.c,v retrieving revision 1.124 diff -u -r1.124 mod_rewrite.c --- mod_rewrite.c 10 Jul 2002 06:01:10 - 1.124 +++ mod_rewrite.c 16 Jul 2002 17:15:33 - @@ -4162,12 +4162,7 @@ : NULL, NULL); - -/* - * XXX: should we add it to err_headers_out as well ? - * if we do we need to be careful that only ONE gets sent out - */ -apr_table_add(r->headers_out, "Set-Cookie", cookie); +apr_table_add(r->err_headers_out, "Set-Cookie", cookie); rewritelog(r, 5, "setting cookie '%s' to '%s'", var, val); } }
RE: [PATCH] 64bit compiler issues
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] > > At 07:23 PM 7/15/2002, Ryan Bloom wrote: > > >We could force the size, by using apr_int32_t. The problem that he is > >having, is that pointers on _most_ 64-bit machines (Windows is a notable > >exception, there may be others), are 64-bits long. But we are using > >int's, which are 32-bits for the pointers. We have the added problem > >that throughout the code, we pass in integers for void *'s. :-( > > Transposed that statement ;-/ > > Pointers on Win64 are 64 bits long, just like you expected. > > Both int and long remain 32 bits long, unlike what you might expect > (and certainly different from Unix.) Ah. Okay, thanks for correcting me. > When we mean a void*, we need to spell out void*. If we need to > pass it through an integer, prove it, and we will consider an > apr_intptr_t type, that could be nothing more complicated than > a union of the appropriate int type and void* for a given platform. Unfortunately, it isn't something we need to do, just something we have done throughout the code for convenience.:-( Ryan
RE: [PATCH] 64bit compiler issues
At 07:23 PM 7/15/2002, Ryan Bloom wrote: >We could force the size, by using apr_int32_t. The problem that he is >having, is that pointers on _most_ 64-bit machines (Windows is a notable >exception, there may be others), are 64-bits long. But we are using >int's, which are 32-bits for the pointers. We have the added problem >that throughout the code, we pass in integers for void *'s. :-( Transposed that statement ;-/ Pointers on Win64 are 64 bits long, just like you expected. Both int and long remain 32 bits long, unlike what you might expect (and certainly different from Unix.) http://www.intel.com/design/itanium/getsoftready/sld011.htm http://www.devx.com/Itanium/art_Porting2.asp The biggest difference is the long value. Since Windows is a P64 OS, rather than the Linux PL64 (both pointers and longs of 64 bits) long becomes a rather dangerous type if you are assuming that it's interchangeable with a pointer. When we mean a void*, we need to spell out void*. If we need to pass it through an integer, prove it, and we will consider an apr_intptr_t type, that could be nothing more complicated than a union of the appropriate int type and void* for a given platform. Bill
RE: [PATCH] 64bit compiler issues
> From: Greg Stein [mailto:[EMAIL PROTECTED]] > > On Mon, Jul 15, 2002 at 02:19:06PM +0200, Peter Poeml wrote: > > Hi, > > > > building httpd-2.0.39 on x86_64 (AMD's upcoming 64 bit architecture) > > there are a few compiler warnings, e.g. due to misfitting type casts. > > > > While some of the warnings can be ignored, I believe that the attached > > patch fixes the relevant issues. > > Nope, sorry. All of those values (namespace IDs) are integer sized. Making > them a "long" is just too big. > > What is the specific error that you were seeing? I would guess that the > problem can be fixed a bit differently, without changing the type of those > indexes. We could force the size, by using apr_int32_t. The problem that he is having, is that pointers on _most_ 64-bit machines (Windows is a notable exception, there may be others), are 64-bits long. But we are using int's, which are 32-bits for the pointers. We have the added problem that throughout the code, we pass in integers for void *'s. :-( Just specify the exact size you want, and this problem should go away. Ryan
Re: HEAD is borked
> David Shane Holden wrote: > > I've noticed this aswell. I have Apache running on a machine using an > > internal > > IP and if I connect to it with another machine using an internal IP it > > sits there > > for exactly 5 minutes before sending back the respone. But if someone > > connects with a real IP from the Internet everything works fine. > > > > I've tested this on both Win2k and Linux. > > > we belive we have found the problem > in the mean time you can use the tag IANH_PRETAG1_2040 > as it appears not to have the problem Who's "we"? Oh, was this more IRC related conversations? david
Re: HEAD is borked
On Mon, Jul 15, 2002 at 10:16:59PM -0700, Justin Erenkrantz wrote: > > Any HTTP/1.1 request is hanging for me (incl. static pages). For me, any HTTP/0.9 request is hanging. GET / hangs, even if folowed by more s. Martin -- <[EMAIL PROTECTED]> | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
