Re: intro and question
On Wed, Oct 03, 2001 at 12:40:13PM -0700, clayton cottingham wrote: [...] unfortunately it doesnt compile! it looks for apr_uri.h and cant find it heck i cant find it either!! its no where to be found in the apr or httpd 2.0 tarballs include dir's am i missing something? Some interfaces have changed since that tarball was released, so you'll have to get the current HEAD from cvs of APR in order to get flood to compile. Let us know if you have problems at that point. -aaron
Re: intro and question
Aaron Bannert wrote: On Wed, Oct 03, 2001 at 12:40:13PM -0700, clayton cottingham wrote: [...] unfortunately it doesnt compile! it looks for apr_uri.h and cant find it heck i cant find it either!! its no where to be found in the apr or httpd 2.0 tarballs include dir's am i missing something? Some interfaces have changed since that tarball was released, so you'll have to get the current HEAD from cvs of APR in order to get flood to compile. Let us know if you have problems at that point. -aaron ok after i retried on my home machine i got as far as this: /bin/sh /home/drfrog/httpd-2.0//srclib/apr/libtool --silent --mode=link gcc -g -O2 -pthread-DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -I/home/drfrog/openssl-0.9.6b/include -I/home/drfrog/httpd-2.0//srclib/apr/include/arch/unix -DAP_HAVE_DESIGNATED_INITIALIZER -I. -I/home/drfrog/httpd-2.0//os/unix -I/home/drfrog/httpd-2.0//server/mpm/prefork -I/home/drfrog/httpd-2.0//modules/http -I/home/drfrog/httpd-2.0//include -I/home/drfrog/httpd-2.0//srclib/apr/include -I/home/drfrog/httpd-2.0//srclib/apr-util/include -I/home/drfrog/httpd-2.0//modules/dav/main -export-dynamic -L/home/drfrog/openssl-0.9.6b/lib -o flood flood.lo flood_round_robin.lo flood_profile.lo flood_config.lo flood_net.lo flood_net_ssl.lo flood_farmer.lo flood_simple_reports.lo flood_easy_reports.lo flood_farm.lo flood_socket_generic.lo flood_socket_keepalive.lo flood_report_relative_times.lo -L/home/drfrog/openssl-0.9.6b/lib /home/drfrog/httpd-2.0//srclib/apr-util/libaprutil.la /home/drfrog/httpd-2.0//srclib/apr/libapr.la /home/drfrog/httpd-2.0//srclib/apr-util/xml/expat/lib/libexpat.la -lm -lcrypt -lnsl -ldl flood_net_ssl.o: In function `ssl_init_socket': /home/drfrog/httpd-test/flood/flood_net_ssl.c:153: undefined reference to `SSL_library_init' /home/drfrog/httpd-test/flood/flood_net_ssl.c:154: undefined reference to `SSL_library_init' /home/drfrog/httpd-test/flood/flood_net_ssl.c:155: undefined reference to `SSL_load_error_strings' /home/drfrog/httpd-test/flood/flood_net_ssl.c:156: undefined reference to `ERR_load_crypto_strings' /home/drfrog/httpd-test/flood/flood_net_ssl.c:157: undefined reference to `RAND_load_file' /home/drfrog/httpd-test/flood/flood_net_ssl.c:160: undefined reference to `CRYPTO_num_locks' /home/drfrog/httpd-test/flood/flood_net_ssl.c:173: undefined reference to `CRYPTO_set_locking_callback' /home/drfrog/httpd-test/flood/flood_net_ssl.c:174: undefined reference to `CRYPTO_set_id_callback' /home/drfrog/httpd-test/flood/flood_net_ssl.c:176: undefined reference to `CRYPTO_set_dynlock_create_callback' /home/drfrog/httpd-test/flood/flood_net_ssl.c:177: undefined reference to `CRYPTO_set_dynlock_lock_callback' /home/drfrog/httpd-test/flood/flood_net_ssl.c:178: undefined reference to `CRYPTO_set_dynlock_destroy_callback' flood_net_ssl.o: In function `ssl_open_socket': /home/drfrog/httpd-test/flood/flood_net_ssl.c:203: undefined reference to `SSLv23_client_method' /home/drfrog/httpd-test/flood/flood_net_ssl.c:203: undefined reference to `SSL_CTX_new' /home/drfrog/httpd-test/flood/flood_net_ssl.c:204: undefined reference to `SSL_CTX_ctrl' /home/drfrog/httpd-test/flood/flood_net_ssl.c:207: undefined reference to `SSL_CTX_ctrl' /home/drfrog/httpd-test/flood/flood_net_ssl.c:210: undefined reference to `SSL_CTX_load_verify_locations' /home/drfrog/httpd-test/flood/flood_net_ssl.c:213: undefined reference to `SSL_new' /home/drfrog/httpd-test/flood/flood_net_ssl.c:214: undefined reference to `SSL_set_connect_state' /home/drfrog/httpd-test/flood/flood_net_ssl.c:217: undefined reference to `SSL_set_fd' /home/drfrog/httpd-test/flood/flood_net_ssl.c:218: undefined reference to `SSL_connect' /home/drfrog/httpd-test/flood/flood_net_ssl.c:222: undefined reference to `SSL_get_error' /home/drfrog/httpd-test/flood/flood_net_ssl.c:232: undefined reference to `ERR_print_errors_fp' flood_net_ssl.o: In function `ssl_close_socket': /home/drfrog/httpd-test/flood/flood_net_ssl.c:243: undefined reference to `SSL_free' /home/drfrog/httpd-test/flood/flood_net_ssl.c:244: undefined reference to `SSL_CTX_free' flood_net_ssl.o: In function `ssl_read_socket': /home/drfrog/httpd-test/flood/flood_net_ssl.c:260: undefined reference to `SSL_read' /home/drfrog/httpd-test/flood/flood_net_ssl.c:261: undefined reference to `SSL_get_error' /home/drfrog/httpd-test/flood/flood_net_ssl.c:275: undefined reference to `ERR_print_errors_fp' flood_net_ssl.o: In function `ssl_read_socket_handshake': /home/drfrog/httpd-test/flood/flood_net_ssl.c:290: undefined reference to `SSL_read' flood_net_ssl.o: In function `ssl_write_socket': /home/drfrog/httpd-test/flood/flood_net_ssl.c:300: undefined reference to `SSL_write' /home/drfrog/httpd-test/flood/flood_net_ssl.c:302: undefined reference to `SSL_get_error' /home/drfrog/httpd-test/flood/flood_net_ssl.c:314: undefined reference to `ERR_print_errors_fp' collect2: ld returned 1 exit status make: *** [flood] Error 1
Re: [PATCH] adding xml output to mod_status -- [REPOST]
- on Linux and NetWare I only get the data unformated back, looks as there are problems with the scoreboard.xsl or so. Any ideas what's Yeah, Mozilla isn't very stable at doing the rendering. Most of the problems you mention are due to the XSLT being done inside the browser. I'm not real worried about problems with the XSL because most of the time you'll want the raw XML data instead, and these browsers will only get better at XSLT over time. 6.29982236431605997495353221893310546875kB If you look in the XSLT I wanted to use xsl:format-number to round to one decimal place, but Mozilla doesn't support format-number yet. You could probably negotiate the xsl file returned based on user-agent and have several. you should really change the TZ to numerous expression as Sander already suggested: Good plan. I wanted to avoid timestamps that are offsets though so the XML data is consistant (and can be compared) across platforms. Cheers, Mark
mod_ssl update...
Yeah, mod_ssl's filtering model just isn't meshing well with the rewrite to the input filtering. Since I think most of us on the list have come to the consensus that what I committed is closer to the right thing (whatever that pie-in-the-sky may be), I think we need to consider altering mod_ssl's filtering model to fit with our new expectations. I think it's doable, but it isn't going to be a trivial one-line patch. I'll quote RSE here from the top of the ssl_engine_io.c: /* XXX THIS STUFF NEEDS A MAJOR CLEANUP -RSE XXX */ So, I'm obviously not the first one to think this and that was before the input filters change forced this issue. =) Anyway, I see that the input and output filters are handled by one function - churn. Is that dictated by the mechanics of OpenSSL? Can we separate input and output entirely or do we need to have them coexist like they are now? Basically, the root problem is that mod_ssl's input filtering routines are expecting to get the socket back with the -1 length and do a FOREACH until it is exhausted. That's not how it works anymore, so mod_ssl is going to be broken until we teach it how to properly handle reading from the socket in little chunks (via ap_get_brigade via CORE_IN). But, I think we may have to jettison CORE_IN when mod_ssl is used because we need to get enough data to renegotiate, etc, etc, etc. I also don't think OpenSSL will like the idea of renegotiating via buckets. =) So, I think we have to teach mod_ssl's input filter to standalone without the help of the core. That means (I think) that we could use the SSL_* (i.e. SSL_read) functions when reading from the socket rather than ap_get_brigade/BIO_*. Can we intermix calls to BIO_* and SSL_*? Are they separate? When do we want to use BIO_* and not SSL_*? There is just a lot of stuff here. And, I think Ralf nailed it on the head. =) I'm not sure that I see a simple way around this, but I'm open to suggestions. Thoughts? -- justin
BaseAddress.ref needed?
Hi Bill, can you please explain if every module really needs an entry in BaseAddress.ref? I tested with many modules without an entry and it seems to work with the linker defaults... If it is needed how should it be done then with 3rd party modules? Guenter.
RE: mod_ssl update...
Hi, Pl. find my comments below : -Original Message- From: Justin Erenkrantz [..snip..] /* XXX THIS STUFF NEEDS A MAJOR CLEANUP -RSE XXX */ So, I'm obviously not the first one to think this and that was before the input filters change forced this issue. =) [..snip..] True.. it's known that the ssl filtering is to be stabilized. That's the reason the comment still exists in the file - else it would have gone long time ago :-). [..snip..] Anyway, I see that the input and output filters are handled by one function - churn. Is that dictated by the mechanics of OpenSSL? Can we separate input and output entirely or do we need to have them coexist like they are now? [..snip..] You're right.. the bulk of the SSL communication logic is done in churn().. The logic basically reads the user data from the filter, gives it to OpenSSL thru' the BIO routines, and whatever is output by openssl is picked up thru' the BIO interfaces and put on to the output queue.. I'm not clear what you mean by separate input and output.. [..snip..] I also don't think OpenSSL will like the idea of renegotiating via buckets. =) [..snip..] I don't think so..As long as we can gather the *full client data* and pass it across, OpenSSL is happy.. The catch here is to capture all the data that's sent by the client, and not to break it into small chunks/pieces. [..snip..] So, I think we have to teach mod_ssl's input filter to standalone without the help of the core. That means (I think) that we could use the SSL_* (i.e. SSL_read) functions when reading from the socket rather than ap_get_brigade/BIO_*. Can we intermix calls to BIO_* and SSL_*? Are they separate? When do we want to use BIO_* and not SSL_*? [..snip..] It's definitely possible to use the SSL_* functions - but, then we'll have to expose the socketfd's et al.. Also, it'd be deviating from the other modules of apache, where the filters are *almost* forced to be used. I'd prefer to have the ap_get_brigade_* functionality to read/write the data from the socket. [..snip..] There is just a lot of stuff here. And, I think Ralf nailed it on the head. =) [..snip..] shameless plugI picked up the SSL filtering logic from tls, and modified it to work for mod-ssl /shameless plug.. OtherBill, Doug, Cliff added some real valuable stuff to the filter code. -Madhu
[PATCH] httpd-2.0: main.c corrects -h on Win32 - update
sorry, I forgot the first usage output... Guenter. main.c.patch
Re: BaseAddress.ref needed?
On Wed, Oct 03, 2001 at 09:56:40AM +0200, Günter Knauf wrote: Hi Bill, can you please explain if every module really needs an entry in BaseAddress.ref? I tested with many modules without an entry and it seems to work with the linker defaults... If it is needed how should it be done then with 3rd party modules? Yes, it is needed. Without it, the linker will assign the same, fixed address to every module. At runtime, those modules will then need to be relocated to some address. Using BaseAddress.ref, we can effectively do the relocation at link time. Sure, it is possible some other code is present and a relocation is forced, but that will be atypical. Relocation is expensive. Doing it at link time rather than load time is a huge win. 3rd party modules can do whatever they want. Invariably, they will probably get relocated and/or clash with other 3rd party modules. But we *do* have control over Apache itself and can help those. There are further optimizations with assigning addresses that we probably don't do. Specifically, if there are gaps in the address space, then you end up wasting space in the processor's mapping tables. As a result, you want to pack the modules as tightly as possible. Of course, that tight-packing is at odds with the optional loading of modules. If we do the packing, then decide not to load something, then we end up with a hole. [ and you can extend that to third party modules if we attempt to act as a registry for them. it goes without saying that people won't have every third party module, so each apache process would have *huge* holes, thus wasting significant processor tables ] Does that answer your questions? :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
[PATCH] proxy_http.c fixed type of pragma var
Hi, with recent changes to mod_proxy now compilition breaks with CW6, CW5 and gcc give warnings. If defining pragma as const char is a problem on other platforms at least a cast it needed. In adddition Pavel told me that gcc warns about this: src/modules/proxy/proxy_http.c:477:4: warning: /* within comment both issues fixed in attached patch2 and tested for NetWare with CW, gcc and for Win32 with MSVC6. Guenter. proxy_http.c.patch proxy_http.c.patch2
Re: [PROPOSAL] Apache for NetWare status change...
Well, if Novell (who support it) feel that way, I'm inclined to say 'provide replacement text to be checked in.' -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: ssl is broken
On Tuesday 02 October 2001 10:11 pm, Justin Erenkrantz wrote: On Wed, Oct 03, 2001 at 12:51:09AM -0400, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: I'm running into all sorts of filter problems. The initial client request is itself not received completely.. For ex., the apr_bucket_read (ssl_engine_io.c:218) returns 20 bytes when the client has sent 103 bytes. The ssl_hook_process_connection (mod_ssl.c:360) returns with a error to read more (which is not being handled right now). This is a problem as the SSL filter expects that *all* the data sent by the client is received in one complete chunk.. If I try forcing the bucket_read again (incase of a SSL_WANT_READ error), it's still not able to read the full data. Whenever mod_ssl is handling the request, it needs to remove CORE_IN and be able to match CORE_IN's functionality (i.e. handle the same modes as CORE_IN). This is how I would expect it to work given the new implementation. This is bogus. The whole point of the SSL module being written to use BIO's, was that it doesn't need to replace CORE_IN. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: BaseAddress.ref needed?
From: Günter Knauf [EMAIL PROTECTED] Sent: Wednesday, October 03, 2001 9:32 AM Hi Greg, Bill, thanks for the detailed information. Now I'm asking me why I did not ask you earlier because I have ~20 modules which then better be recompiled... I assume that this also applies to Cygwin and perhaps OS2, or? If so then there's a common interest to have a BaseAddress2.ref for 3rd party modules; can we perhaps place it on a Apache server so that everyone has access to? I've already started with this and will now put in all modules I got compiled for Win32 and post it here if you agree... My only problem is that I don't want to even try maintaining such a beast. IMHO, it's better if they express their /BASE:0x directly. Of course I don't mind if an 'installer' were to tack their base entry into BaseAddr.ref directly when merging their sources into the build tree (not such a common act on Win32, since we have so few 'compilers'.) One problem is the size argument. If you build in full debugging mode, your binaries are much larger. I've taken that into account for the current list. Sometimes modules grow, and the entire table must be rearranged. I don't much like trying that for umpteen modules. Look at the rebase.exe utility (provided in the PlatformSDK and with the MSVC products, amoungst other places) which will let you reorder .dll's wrt each other's load addresses. You would specify any 'predictable' modules (those with well established load addresses, such as libraries or the Apache modules we hand-ordered) by the -N opt, then list out the other 'undefined' modules with the -O opt. Use -d to order these modules top-down, and -b 0x6FFF or some such as the starting point. cygwin might benefit from rebasing the entire list at once. Bill
--enable-ssl=shared
autoconf guru help needed: -lssl and -lcrypto are linked with httpd rather than mod_ssl.so since httpd does not reference any ssl symbols they are all tossed out and mod_ssl.so falls flat on its face: Cannot load /home/dougm/ap/prefork/modules/mod_ssl.so into server: /home/dougm/ap/prefork/modules/mod_ssl.so: undefined symbol: X509_free
Apache 1.3.21 tag this evening....
...after porting Bill Rowe's last mod_negotiation patch to 1.3. These showstoppers are in the STATUS file... Netware, OS2, and MPE may require gettid() and tid_t definitions in those platforms' os.h headers for mod_unique_id. Status: Win32 OK. Netware ??. OS2 ??. MPE ??. Security issues posted to the appropriate list. Status: some applied I believe both have been taken care of and will remove these from the STATUS file before tag if someone doesn;t beat me to it first. Will roll the tarball 24 hours from the tag to give time for some testing. Bill
Re: mod_ssl update...
On Wed, Oct 03, 2001 at 01:30:02AM -0700, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: You're right.. the bulk of the SSL communication logic is done in churn().. The logic basically reads the user data from the filter, gives it to OpenSSL thru' the BIO routines, and whatever is output by openssl is picked up thru' the BIO interfaces and put on to the output queue.. I'm not clear what you mean by separate input and output.. Most of the other filters have their logic separated by input and output. mod_ssl combines them into one function. I think that it makes sense to split it out so that input is only handled by one function and output is handled by another function. I'm not sure why we have one function attempting to handle input/output. Is there a reason why churn() must exist? Input and output are not related to each other. I'm not familiar with the BIO_* routines (when I was writing the SSL code for flood, the BIO_* routines did not work for me). So, I had it handle reading from the socket itself - and that seemed to work out well. I don't think so..As long as we can gather the *full client data* and pass it across, OpenSSL is happy.. The catch here is to capture all the data that's sent by the client, and not to break it into small chunks/pieces. What the real deal is that OpenSSL was assumming that it'd get the socket bucket back from the core filter and it'd be able to do whatever it wanted with it. That's not possible anymore. If it is possible to have the core do the heavy lifting (i.e. reading from the socket), that is preferred. I'm just not sure how mod_ssl is reading from the socket at all. It calls ap_get_brigade *and* SSL_read - that is a violation of the input filter semantics. Either it reads from the socket on its own or it relies on the core for all of the input. It's definitely possible to use the SSL_* functions - but, then we'll have to expose the socketfd's et al.. Also, it'd be deviating from the other modules of apache, where the filters are *almost* forced to be used. I'd prefer to have the ap_get_brigade_* functionality to read/write the data from the socket. Yes, I'd prefer it to rely on core, but there are things like *readbytes 0 that are completely bogus in the core with SSL. That's why I'm not sure we can use the core filter anymore. Since all of the data in the socket is encrypted, if readbytes == 0 is sent, it means to read a line of input data which is now bogus because the core (since it can't read the actual socket information) can't determine when a line of input data is read. Only mod_ssl has the logic to decrypt the packet information. (And look at flood to see how you get the socketfd back from the apr_socket_t...) -- justin
Re: --enable-ssl=shared
On Wed, Oct 03, 2001 at 08:18:30AM -0700, Doug MacEachern wrote: autoconf guru help needed: -lssl and -lcrypto are linked with httpd rather than mod_ssl.so since httpd does not reference any ssl symbols they are all tossed out and mod_ssl.so falls flat on its face: Cannot load /home/dougm/ap/prefork/modules/mod_ssl.so into server: /home/dougm/ap/prefork/modules/mod_ssl.so: undefined symbol: X509_free So you're saying that libssl.so and libcrypto.so aren't showing up when you run ldd on either httpd or mod_ssl.so? Just for reference, what is ldd giving you for httpd and mod_ssl.so? (You may not want to copy it here, but ldd -v is interesting too). -aaron
Re: Apache 1.3.21 tag this evening....
On Wed, 3 Oct 2001 11:27:56 -0400, Bill Stoddard wrote: ...after porting Bill Rowe's last mod_negotiation patch to 1.3. These showstoppers are in the STATUS file... Netware, OS2, and MPE may require gettid() and tid_t definitions in those platforms' os.h headers for mod_unique_id. Status: Win32 OK. Netware ??. OS2 ??. MPE ??. gettid()? 1.3 on OS/2 is NOT multi-threaded. -- __ | Brian Havard | He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy! - Life of Brian | --
Re: --enable-ssl=shared
On Wed, 3 Oct 2001, Aaron Bannert wrote:
So you're saying that libssl.so and libcrypto.so aren't showing up
when you run ldd on either httpd or mod_ssl.so? Just for reference,
what is ldd giving you for httpd and mod_ssl.so? (You may not want to
copy it here, but ldd -v is interesting too).
no, mine is linked against lib{crypto,ssl}.a
there are no .so's in /usr/local/ssl/lib
i'm just noticing now for the first time lib{crypto,ssl}.so in /usr/lib
but if mod_ssl is built shared, -lssl -lcrypto should get linked against
mod_ssl.so rather than httpd, right?
% ldd bin/httpd
libaprutil.so.0 = /home/dougm/ap/prefork/lib/libaprutil.so.0 (0x40017000)
libapr.so.0 = /home/dougm/ap/prefork/lib/libapr.so.0 (0x40028000)
libm.so.6 = /lib/libm.so.6 (0x40052000)
libcrypt.so.1 = /lib/libcrypt.so.1 (0x40071000)
libnsl.so.1 = /lib/libnsl.so.1 (0x400a)
libdl.so.2 = /lib/libdl.so.2 (0x400b7000)
libexpat.so.0 = /home/dougm/ap/prefork/lib/libexpat.so.0 (0x400ba000)
libpthread.so.0 = /lib/libpthread.so.0 (0x400e1000)
libc.so.6 = /lib/libc.so.6 (0x400f7000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)
% ldd modules/mod_ssl.so
libc.so.6 = /lib/libc.so.6 (0x40032000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000)
Re: Apache 1.3.21 tag this evening....
#define for gettid() and tid_t have been added to os.h for NetWare Brad [EMAIL PROTECTED] Wednesday, October 03, 2001 9:27:56 AM ..after porting Bill Rowe's last mod_negotiation patch to 1.3. These showstoppers are in the STATUS file... Netware, OS2, and MPE may require gettid() and tid_t definitions in those platforms' os.h headers for mod_unique_id. Status: Win32 OK. Netware ??. OS2 ??. MPE ??. Security issues posted to the appropriate list. Status: some applied I believe both have been taken care of and will remove these from the STATUS file before tag if someone doesn;t beat me to it first. Will roll the tarball 24 hours from the tag to give time for some testing. Bill
Re: Apache 1.3.21 tag this evening....
I've written an Announcement file for 1.3.21 and will commit within the hour (just got back from dentist) Mark
Re: ssl is broken
On Wed, Oct 03, 2001 at 08:10:11AM -0500, William A. Rowe, Jr. wrote: Now ... the core input filter can't decide where to break input, it has to allow connection filters to insert themselves and decode whatever is read. That means that the core filter needs to be split, and another line input dequeue filter needs to be inserted as the last 'connection' filter. That leaves us ready for the request filter to read 'lines' or 'bytes' and make decisions based on the lines and bytes read, and fall back on the line input dequeue to keep the 'next' request's input set-aside for the next request. Yes and no. You are kind of right here - I see why you might want to do that, but that was the previous architecture with HTTP_IN and CORE_IN. (HTTP_IN was an admittedly bad name for it, but that is what it tried to do - do readlines.) A lot of the complexity was removed by assuming that only one filter has the -1 brigade. And, Greg and Ryan have commented that they would rather see CORE_IN not deal with socket buckets at all but read directly from the socket. Ryan and Greg, how do you guys see this working? I yield to your wisdom here... If the CORE_IN read from the socket directly as you both have suggested, how would (or should) mod_ssl interact? I see it being a much simpler task to write a module that replaces CORE_IN than trying to work around it. It's not that much code - and I think mod_ssl could even ditch some of the lesser-supported modes (readbytes==-1 and PEEK which it already doesn't support). We'll probably end up removing them in core at some point. -- justin
Re: Apache 1.3.21 tag this evening....
Doh --- sorry :) I'll pull that note.
Could all platforms crosscheck the mod_vhost_alias/mod_unique_id changes that
went in? The changes vhost_alias changes _should_ have no discernable effect
on any straight unix ('/' rooted) platform, and the unique_id changes should
only affect MULTITHREAD platforms.
Don't want to discover that I've broken this -after- the tag, I'd like to
fix any snafus beforehand.
Bill
- Original Message -
From: Brian Havard [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, October 03, 2001 10:41 AM
Subject: Re: Apache 1.3.21 tag this evening
On Wed, 3 Oct 2001 11:27:56 -0400, Bill Stoddard wrote:
...after porting Bill Rowe's last mod_negotiation patch to 1.3.
These showstoppers are in the STATUS file...
Netware, OS2, and MPE may require gettid() and tid_t definitions in
those platforms' os.h headers for mod_unique_id.
Status: Win32 OK. Netware ??. OS2 ??. MPE ??.
gettid()? 1.3 on OS/2 is NOT multi-threaded.
--
__
| Brian Havard | He is not the messiah! |
| [EMAIL PROTECTED] | He's a very naughty boy! - Life of Brian |
--
Re: [PATCH] mod_negotiation, suffix order
William A. Rowe, Jr. wrote: That is, if the URI is index.bak, we can only negociate amongst variants matching index.bak* -- NOT index.*.bak*. What's your rational? I agree that index[.*].bak[.*] is broader than index.bak[.*] --- but I'm wondering why you feel this way? Say that we want to point the user to the english index page. Why shouldn't a request for index.en discover index.html.en or index.cgi.en? Negociation is done using the header field values, NOT the URI. index.en is NOT a request for an English variant of index, it is a request for [possibly some variant of] an object named index.en -- period. That a portion of the specified URI happens to match a value that has meaning in negociation is completely coincidental -- and irrelevant. We cannot co-opt nor interpret nor decompose the value of the URI in negociation; all we can use are the parameters in the header and the resource (read: file) names. If it were meant to be used as a negociation axis, it would be in the header fields and absent from the URI. That it is explicit in the URI removes it from participation in any negociation axes. If the URI is index.en, an explicitly English variant must match index.en*.en*. Ordering is an issue for sure, but playing games, by decomposing the URI and trying to guess what it means, only complicates matters and is not on. All IM[NS?]HO.. although Roy may have something to say on this. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
RE: --enable-ssl=shared
You're right.. libcrypto/ssl.a should get linked with mod_ssl.so rather than
httpd. I did try it out initially - with a small hack into the ssl makefile,
but then gave up - as it involved modifying the autoconf script(something
which i don't know).
Thx
-Madhu
-Original Message-
From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 03, 2001 8:47 AM
To: [EMAIL PROTECTED]
Subject: Re: --enable-ssl=shared
On Wed, 3 Oct 2001, Aaron Bannert wrote:
So you're saying that libssl.so and libcrypto.so aren't showing up
when you run ldd on either httpd or mod_ssl.so? Just for reference,
what is ldd giving you for httpd and mod_ssl.so? (You may not want to
copy it here, but ldd -v is interesting too).
no, mine is linked against lib{crypto,ssl}.a
there are no .so's in /usr/local/ssl/lib
i'm just noticing now for the first time lib{crypto,ssl}.so in /usr/lib
but if mod_ssl is built shared, -lssl -lcrypto should get linked against
mod_ssl.so rather than httpd, right?
% ldd bin/httpd
libaprutil.so.0 = /home/dougm/ap/prefork/lib/libaprutil.so.0
(0x40017000)
libapr.so.0 = /home/dougm/ap/prefork/lib/libapr.so.0 (0x40028000)
libm.so.6 = /lib/libm.so.6 (0x40052000)
libcrypt.so.1 = /lib/libcrypt.so.1 (0x40071000)
libnsl.so.1 = /lib/libnsl.so.1 (0x400a)
libdl.so.2 = /lib/libdl.so.2 (0x400b7000)
libexpat.so.0 = /home/dougm/ap/prefork/lib/libexpat.so.0
(0x400ba000)
libpthread.so.0 = /lib/libpthread.so.0 (0x400e1000)
libc.so.6 = /lib/libc.so.6 (0x400f7000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)
% ldd modules/mod_ssl.so
libc.so.6 = /lib/libc.so.6 (0x40032000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000)
Re: Apache 1.3.21 tag this evening....
Is MPE actually a threaded server, or am I simply confused? Are there any MULTITHREAD unix ports, or is this only Win32 and Netware? Bill - Original Message - From: Brad Nicholes [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, October 03, 2001 10:51 AM Subject: Re: Apache 1.3.21 tag this evening #define for gettid() and tid_t have been added to os.h for NetWare Brad [EMAIL PROTECTED] Wednesday, October 03, 2001 9:27:56 AM ..after porting Bill Rowe's last mod_negotiation patch to 1.3. These showstoppers are in the STATUS file... Netware, OS2, and MPE may require gettid() and tid_t definitions in those platforms' os.h headers for mod_unique_id. Status: Win32 OK. Netware ??. OS2 ??. MPE ??. Security issues posted to the appropriate list. Status: some applied I believe both have been taken care of and will remove these from the STATUS file before tag if someone doesn;t beat me to it first. Will roll the tarball 24 hours from the tag to give time for some testing. Bill
CGI -C++ Library
Dear All, I am a new joinee in this group. I am now working on CGI-C++ development. I would like to know the C++ libraries, if any, that are supported by Apache 1.3 for this development. I loaded Apache on HP-Unix version 11 box. Regards, Madhu. --- William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Is MPE actually a threaded server, or am I simply confused? Are there any MULTITHREAD unix ports, or is this only Win32 and Netware? Bill - Original Message - From: Brad Nicholes [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, October 03, 2001 10:51 AM Subject: Re: Apache 1.3.21 tag this evening #define for gettid() and tid_t have been added to os.h for NetWare Brad [EMAIL PROTECTED] Wednesday, October 03, 2001 9:27:56 AM ..after porting Bill Rowe's last mod_negotiation patch to 1.3. These showstoppers are in the STATUS file... Netware, OS2, and MPE may require gettid() and tid_t definitions in those platforms' os.h headers for mod_unique_id. Status: Win32 OK. Netware ??. OS2 ??. MPE ??. Security issues posted to the appropriate list. Status: some applied I believe both have been taken care of and will remove these from the STATUS file before tag if someone doesn;t beat me to it first. Will roll the tarball 24 hours from the tag to give time for some testing. Bill __ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com
Re: [PATCH] fix --enable-mods-shared=most for compiled-in modules
On Tuesday 02 October 2001 11:29 am, Aaron Bannert wrote: Committed. Thanks, Ryan On Mon, Oct 01, 2001 at 09:20:41PM -0700, Ryan Bloom wrote: We should fix the configure script so that it automatically adds the LoadModule line, just like it did in 1.3. This patch fixes the problem described in the STATUS file whereby modules that are compiled-in by default would not be enabled as DSOs when the --enable-mods-shared=most parameter was passed to configure. A new enable state was invented: static. This is specified as a param to the APACHE_MODULE() macro to specify that a particular module shall not be compiled as a DSO (unless specifically overridden by name). mod_so and mod_http have been set to static in this patch. This patch should not affect anyone who normally omits --enable-mods-shared from their configure parameters. I will follow up this patch in a few days with a patch to have configure properly build the LoadModule directives for httpd.conf at install time (as noted by Ryan above and in the STATUS diff below)... -aaron Index: STATUS === RCS file: /home/cvspublic/httpd-2.0/STATUS,v retrieving revision 1.297 diff -u -r1.297 STATUS --- STATUS2001/09/28 17:53:02 1.297 +++ STATUS2001/10/02 18:17:28 @@ -95,12 +95,9 @@ to make it agree with the operation of the StartServers directive. -* configure --enable-mods-shared=most option has issues. Example: - - ./configure --enable-mods-shared=most - -This builds mod_headers as a DSO (good) but builds mod_mime -as a compiled-in module (bad). +* Fix the configure script to add a LoadModule directive to + the default httpd.conf for any module that was compiled + as a DSO. * revamp the input filter semantics, per discussions since February (and especially at the hackathon last Index: acinclude.m4 === RCS file: /home/cvspublic/httpd-2.0/acinclude.m4,v retrieving revision 1.101 diff -u -r1.101 acinclude.m4 --- acinclude.m4 2001/09/30 07:57:14 1.101 +++ acinclude.m4 2001/10/02 18:17:29 @@ -199,6 +199,7 @@ dnl yes -- enabled by default. user must explicitly disable. dnl no -- disabled under default, most, all. user must explicitly enable. dnl most -- disabled by default. enabled explicitly or with most or all. +dnl static -- enabled as static by default, must be explicitly changed. dnl -- disabled under default, most. enabled explicitly or with all. dnl dnl basically: yes/no is a hard setting. most means follow the most @@ -218,11 +219,16 @@ else _apmod_error_fatal=yes fi - if test $enable_$1 = most; then + if test $enable_$1 = static; then +enable_$1=yes + elif test $enable_$1 = yes; then +enable_$1=$module_default +_apmod_extra_msg= ($module_selection) + elif test $enable_$1 = most; then if test $module_selection = most -o $module_selection = all; then enable_$1=$module_default _apmod_extra_msg= ($module_selection) -else +elif test $enable_$1 != yes; then enable_$1=no fi elif test $enable_$1 = maybe-all; then Index: modules/http/config2.m4 === RCS file: /home/cvspublic/httpd-2.0/modules/http/config2.m4,v retrieving revision 1.1 diff -u -r1.1 config2.m4 --- modules/http/config2.m4 2001/04/18 20:56:04 1.1 +++ modules/http/config2.m4 2001/10/02 18:17:29 @@ -4,7 +4,8 @@ http_objects=http_core.lo http_protocol.lo http_request.lo -APACHE_MODULE(http, HTTP protocol handling, $http_objects, , yes) +dnl mod_http freaks out when built as a DSO +APACHE_MODULE(http, HTTP protocol handling, $http_objects, , static) APACHE_MODULE(mime, mapping of file-extension to MIME, , , yes) APACHE_MODPATH_FINISH Index: modules/mappers/config9.m4 === RCS file: /home/cvspublic/httpd-2.0/modules/mappers/config9.m4,v retrieving revision 1.3 diff -u -r1.3 config9.m4 --- modules/mappers/config9.m42001/04/29 05:24:10 1.3 +++ modules/mappers/config9.m42001/10/02 18:17:29 @@ -23,7 +23,7 @@ dnl ### it here. we need to shift *this* config.m4 to be last or we dnl ### need to find a different way to set up this default and module spec. if test $sharedobjs = yes; then -APACHE_MODULE(so, DSO capability, , , yes) +APACHE_MODULE(so, DSO capability, , , static) else APACHE_MODULE(so, DSO capability, , , no) fi -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
RE: Apache 1.3.21 tag this evening....
MPE is still 1.3.x pre-fork only. As part of my day job, I will start a project in December to update the bundled Apache server within the MPE OS to the latest greatest 1.3.x version. If I have time, I may also investigate 2.x and threading. So far nobody has yet played with Apache 2.x on MPE to the best of my knowledge. - Mark B. (aka [EMAIL PROTECTED]) -Original Message- From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 03, 2001 9:45 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Apache 1.3.21 tag this evening Is MPE actually a threaded server, or am I simply confused?
[PATCH] Build Apache 1.3 on Darwin 1.4.1, MacOS X 10.1
All, The following patch lets Apache build on the MacOSX 10.1 platform: === RCS file: /home/cvspublic/apache-1.3/src/Configure,v retrieving revision 1.433 diff -u -r1.433 Configure --- Configure 2001/10/03 12:59:03 1.433 +++ Configure 2001/10/03 18:27:19 @@ -1149,7 +1149,14 @@ *-apple-rhapsody* | *-apple-darwin* ) LD_SHLIB=cc CFLAGS_SHLIB= - LDFLAGS_SHLIB='$(EXTRA_LDFLAGS) -bundle -undefined suppress' + case $PLAT in + *-apple-darwin1.4 ) + LDFLAGS_SHLIB='$(EXTRA_LDFLAGS) -bundle -undefined suppress -flat_namespace' + ;; + * ) + LDFLAGS_SHLIB='$(EXTRA_LDFLAGS) -bundle -undefined suppress' + ;; + esac LDFLAGS_MOD_SHLIB=$LDFLAGS_SHLIB LDFLAGS_SHLIB_EXPORT= SHLIB_SUFFIX_DEPTH=0 === Discussion: On 10.1 (Darwin 1.4.1), Apple introduced a feature called Two-Level Namespace Executables where symbols are recorded along with the library they are to be loaded from. Cool feature, but it breaks the Apache build because it doesn't allow leaving symbols undefined. My patch moves us back to the flat namespace. Apple themselves attempt to fix this the correct way (from the src/Configure in the package that the MacOSX/Darwin apache is built with): LDFLAGS_SHLIB='$(EXTRA_LDFLAGS) -bundle -bundle_loader /usr/sbin/httpd' ...where they provide the file that contains the missing symbols. However, this has two disadvantages: 1) hard-coding a path to the executable 2) expects to find an executable already compiled, so this will only build on systems that already have a httpd in that place. Chicken and egg. If my impression from the make output is correct, httpd gets linked *last* so will not be available for its modules to link against. So, I suggest to go back to the old ways for now. Test status: Works On My Laptop. (: S. -- Covalent Technologies [EMAIL PROTECTED] Engineering groupVoice: (415) 536 5214 645 Howard St. Fax: (415) 536 5210 San Francisco CA 94105 PGP Fingerprint: 1E74 4E58 DFAC 2CF5 6A03 5531 AFB1 96AF B584 0AB1 === This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message ===
RE: Apache 1.3.21 tag this evening....
I'm hitting a fatal compilation error on TPF with some accept mutex code what was added. I was unaware of these changes but believe it was part of the make-accept-mutex-method-runtime patch. (I didn't realize the changes affected TPF-specific code until today.) I think I have a fix but won't be able to test it for several hours (7pm Eastern Time). Can the tag wait until I've tested and submitted this fix? -David
input filter changes/breaking in proxy
hey guys. I'm trying to debug a problem with the reverse proxy in the latest CVS HEAD. It seems to be handing in ap_proxy_read_string, while doing a blocking read with 'ap_get_brigade' Is anyone else having this problem? I'm not doing anything 'smart' just a plain ProxyPass /test/ http://foo/test/ ..Ian
Re: [PATCH] mod_negotiation, suffix order
On Tue, Oct 02, 2001 at 08:33:21PM -0500, William A. Rowe, Jr. wrote:
I am very impressed by this idea for Apache 2.0. But I don't like the
many to many mapping. If we change your underlying rule here to require
that each filename extension is passed in sequence, I would be _very_
happy to commit this patch :) E.g. index.en _could_ match index.html.en.
But index.en.html would _not_ match index.html.en.
By that, I take it you mean something like a requirement (5), or
perhaps (3b), to be added to the description below, along the lines of
(3b)each .suffix in r-filename must exist in the real filename, in
the same sequence as they were in r-filename? (r-filename here
means the bit of it after the final /)
The requirements are (1)r-filename up to the first dot must match the
real filename up to the first dot; (2)r-filename may not be longer
than the real filename; (3)each .suffix in r-filename must exist
(string match) in the real filename; (4)the real filename must
correspond to a known mime-type, encoding, etc -- which I think means
that the final suffix must be known, and only suffixes followed by
known suffixes are considered.
[ I note that others feel that (1) above should be replaced with
something more like all of r-filename must match the start of the
real filename, which would make the remainder of this mail
irrelevant. I'll continue anyway, but feel free to bin it if this is
the Wrong Thing ]
In case my interpretation of (3b) is unclear: as a (hopefully)
complete example, given the file name.a.b.x.cd.e.f, and presuming
that x is the only suffix which is _not_ a recognised mime extension
(type, language, encoding, whatever) then which of the following
requests should be accepted, and which not?
name
name.a
name.a.b
name.a.c
name.a.cd
name.b.c.e
name.b.x.e.f
name.e
name.x.c
name.x.f
name.a.b...f
name.b.a
name.a.b.f.c
name.x.b
name.c.x
name.f.e
name.e.
name.e.e
name.f.
(my understanding is that the first group should all be passed down as
possibilities, the second group shouldn't, and the third group could
be anything. I'd plump for yes for all three, probably.)
And for extra fun, which would be different if the file were called
name.a.b.x.cd.e.f.e.
(my understanding is that the third group definitely becomes yes,
name.f.e from the second group becomes yes, and the rest stay as
they were.)
As mentioned in the earlier mail, this patch just decides whether or
not to allow the file as a possibility -- later code gets a shot at
deciding how to handle the suffixes, so if any of the trailing
not-explicitly-listed-in-r-filename suffixes aren't actually
recognised, the only way to get the file would be to request it
by the full name, and therefore bypass mod_negotiation.
For the specific example above, this means that the only requests that
would actually return the file would be name.b.x.e.f, name.x.c, and
name.x.f
The change to the patch to limit the matches as described above is
mostly straightforward -- instead of starting each strstr() at the
start of name, start it at the point of the previous match (either
the start or the end -- it'd presumably make a difference if someone
requests file.html.html).
A new const char * which points into dirent.name is the only addition
over the previous patch. However, unless someone has a
case-insensitive strstr() lying around, the CASE_BLIND_FILESYSTEM
cases won't work sensibly -- the name part would match
insensitively, but each suffix won't.
I'm including the reworked patch below, in case it's considered
useful. Written and somewhat tested against mod_negotiation.c from
httpd-2.0.25; it applies cleanly to CVS version 1.84.
f
--
Francis Daly[EMAIL PROTECTED]
=
--- mod_negotiation.c.orig Tue Aug 28 04:08:31 2001
+++ mod_negotiation.c Wed Oct 3 21:44:12 2001
@@ -1019,6 +1019,11 @@
struct var_rec mime_info;
struct accept_rec accept_info;
void *new_var;
+char *pos;
+int pos_len;
+int not_this_dirent;/* actually, boolean. */
+int dots_in_request = 0;/* 1 == one dot, 2 == some dots */
+const char *dpos; /* points into the dirent.name */
int anymatch = 0;
clean_var_rec(mime_info);
@@ -1041,20 +1046,92 @@
return HTTP_FORBIDDEN;
}
+if ((pos = strchr(filp, '.'))) {
+dots_in_request = 1;
+if (strchr(++pos, '.')) {
+dots_in_request = 2;
+}
+}
+
while (apr_dir_read(dirent, APR_FINFO_DIRENT, dirp) == APR_SUCCESS) {
apr_array_header_t *exception_list;
request_rec *sub_req;
-/* Do we have a match? */
+if (!dots_in_request) {
+
+/* Given name, check for name. */
#ifdef CASE_BLIND_FILESYSTEM
-if (strncasecmp(dirent.name, filp, prefix_len)) {
+if (strncasecmp(dirent.name, filp, prefix_len)) {
#else
-if (strncmp(dirent.name, filp, prefix_len)) {
+if
Recent Input Filter changes breaking reverse proxy --repost
hey guys. I'm trying to debug a problem with the reverse proxy in the latest CVS HEAD. It seems to be handing in ap_proxy_read_string, while doing a blocking read with 'ap_get_brigade' Is anyone else having this problem? I'm not doing anything 'smart' just a plain ProxyPass /test/ http://foo/test/ ..Ian
Re: BaseAddress.ref needed?
Hi Bill, My only problem is that I don't want to even try maintaining such a beast. IMHO, it's better if they express their /BASE:0x directly. I'm also too lazy, so I made a quick hack in perl which could do the beast for us. My idea is using a file modules.def which defines the Apache shipping modules, and a second mymodules.def which is appended when present. modules.def ships with Apache and everyone who is using own modules has only to maintain a small mymodules.def with the modules he uses. So you can reorder, comment out, insert modules and make a gap just as you like, the script does the rest. The module definition is simply the name and the bytes separated by comma. What do you think? Guenter. mkbaseref.zip
Re: Apache 1.3.21 tag this evening....
I'll hold off on the tag for a few hours more. Bill - Original Message - From: David McCreedy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 03, 2001 3:17 PM Subject: RE: Apache 1.3.21 tag this evening I'm hitting a fatal compilation error on TPF with some accept mutex code what was added. I was unaware of these changes but believe it was part of the make-accept-mutex-method-runtime patch. (I didn't realize the changes affected TPF-specific code until today.) I think I have a fix but won't be able to test it for several hours (7pm Eastern Time). Can the tag wait until I've tested and submitted this fix? -David
1.3 src/Configure
I know I was one of the last holdouts that used the old src/Configure method, before being converted to APACI. Which suddenly makes me wonder.. is there *anyone* that still uses src/Configure? Does anyone know if it still works? :-) -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: 1.3 src/Configure
Yes... src/Configure is used on TPF. And it still works. -David Rodent of Unusual Size To: Apache Developers [EMAIL PROTECTED] Ken.Coar@Golu cc: x.Com Subject: 1.3 src/Configure 10/03/2001 05:53 PM Please respond to dev I know I was one of the last holdouts that used the old src/Configure method, before being converted to APACI. Which suddenly makes me wonder.. is there *anyone* that still uses src/Configure? Does anyone know if it still works? :-) -- #ken P-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
[PATCH] TPF http_main.c change for 1.3.21
Here is the http_main.c change to fix the compilation error on TPF. It's change is within an #if defined(HAVE_TPF_CORE_SERIALIZED_ACCEPT) block of code so it should not affect any other platforms. Thank you, David McCreedy
[PATCH (again)] TPF http_main.c change for 1.3.21
Here is the http_main.c change to fix the compilation error on TPF.
(I omitted the actual patch on my first note.)
It's change is within an #if defined(HAVE_TPF_CORE_SERIALIZED_ACCEPT)
block of code so it should not affect any other platforms.
Thank you,
David McCreedy
diff -ru3 before/src/main/http_main.c after/src/main/http_main.c
--- before/src/main/http_main.c Wed Oct 3 19:30:29 2001
+++ after/src/main/http_main.c Wed Oct 3 19:28:44 2001
@@ -1074,7 +1074,9 @@
coruc(RESOURCE_KEY);
}
-#define accept_mutex_init_tpfcore(x)
+static void accept_mutex_init_tpfcore(pool *foo)
+{
+}
static void accept_mutex_child_init_tpfcore(pool *p)
{
Re: 1.3 src/Configure
on 10/3/01 4:53 PM, Rodent of Unusual Size at [EMAIL PROTECTED] wrote: I know I was one of the last holdouts that used the old src/Configure method, before being converted to APACI. Which suddenly makes me wonder.. is there *anyone* that still uses src/Configure? Does anyone know if it still works? :-) Isn't apache-1.3/src/Configure called by apache-1.3/configure ? At least, when I fixed my build in src/Configure, things started working. See my patch of earlier today. S. -- Covalent Technologies [EMAIL PROTECTED] Engineering groupVoice: (415) 536 5214 645 Howard St. Fax: (415) 536 5210 San Francisco CA 94105 PGP Fingerprint: 1E74 4E58 DFAC 2CF5 6A03 5531 AFB1 96AF B584 0AB1 === This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message ===
Re: BaseAddress.ref needed?
Nope. Maintaining a list of base addresses implies some intimate knowledge of the size of the code segment, which we aren't privy to, and will change over a modules' lifetime based on the type of compilation and whether it draws in static or dynamic libraries. It also presumes perl is installed - something others have criticized me before. That's why we've settled on awk. Bill - Original Message - From: Günter Knauf [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 03, 2001 4:52 PM Subject: Re: BaseAddress.ref needed? Hi Bill, My only problem is that I don't want to even try maintaining such a beast. IMHO, it's better if they express their /BASE:0x directly. I'm also too lazy, so I made a quick hack in perl which could do the beast for us. My idea is using a file modules.def which defines the Apache shipping modules, and a second mymodules.def which is appended when present. modules.def ships with Apache and everyone who is using own modules has only to maintain a small mymodules.def with the modules he uses. So you can reorder, comment out, insert modules and make a gap just as you like, the script does the rest. The module definition is simply the name and the bytes separated by comma. What do you think? Guenter.
[PATCH] Remove the Port directive.
This patch completely deprectates the Port directive. The ServerName
directive is now overloaded, so that admins specify the port and name on
the same directive. It also makes Listen a required directive. Pay attention
to that. There are no default ports with this patch. If your config doesn't have
a Listen directive, the server doesn't start, and it emits an error.
I am a bit hesitant to commit this without some feedback, because it is a pretty
major change. Before I commit this, I will update all of the docs.
Thoughts?
Ryan
? build.log
? build.err
? modules/httpd-pop3
? srclib/apr/build.log
? srclib/apr/build.err
? srclib/apr/test/build.log
? srclib/apr/test/build.err
Index: docs/conf/httpd-std.conf
===
RCS file: /home/cvs/httpd-2.0/docs/conf/httpd-std.conf,v
retrieving revision 1.52
diff -u -d -b -w -u -r1.52 httpd-std.conf
--- docs/conf/httpd-std.conf2001/10/03 18:56:38 1.52
+++ docs/conf/httpd-std.conf2001/10/04 02:49:00
@@ -231,12 +231,6 @@
#
#
-# Port: The port to which the standalone server listens. For
-# ports 1023, you will need httpd to be run as root initially.
-#
-Port @@Port@@
-
-#
# If you wish httpd to run as a different user or group, you must run
# httpd as root initially and it will switch.
#
@@ -270,7 +264,7 @@
# You will have to access it by its address (e.g., http://123.45.67.89/)
# anyway, and this will make redirections work in a sensible way.
#
-#ServerName new.host.name
+#ServerName new.host.name:80
#
# DocumentRoot: The directory out of which you will serve your
Index: server/core.c
===
RCS file: /home/cvs/httpd-2.0/server/core.c,v
retrieving revision 1.64
diff -u -d -b -w -u -r1.64 core.c
--- server/core.c 2001/09/29 08:33:02 1.64
+++ server/core.c 2001/10/04 02:49:02
@@ -1603,15 +1603,27 @@
return NULL;
}
-static const char *server_port(cmd_parms *cmd, void *dummy, const char *arg)
+static const char *server_hostname_port(cmd_parms *cmd, void *dummy, const char *arg)
{
const char *err = ap_check_cmd_context(cmd, NOT_IN_DIR_LOC_FILE|NOT_IN_LIMIT);
+const char *portstr;
+const char *server;
int port;
if (err != NULL) {
return err;
}
-port = atoi(arg);
+portstr = ap_strchr_c(arg, ':');
+if (portstr) {
+cmd-server-server_hostname = apr_pstrndup(cmd-pool, arg,
+portstr - arg);
+portstr++;
+port = atoi(portstr);
+}
+else {
+cmd-server-server_hostname = apr_pstrdup(cmd-pool, arg);
+port = 80;
+}
if (port = 0 || port = 65536) { /* 65536 == 116 */
return apr_pstrcat(cmd-temp_pool, The port number \, arg,
\ is outside the appropriate range
@@ -2411,7 +2423,8 @@
/* Old server config file commands */
-AP_INIT_TAKE1(Port, server_port, NULL, RSRC_CONF, A TCP port number),
+AP_INIT_TAKE1(Port, ap_set_deprecated, NULL, RSRC_CONF,
+ Port was replaced with Listen in Apache 2.0),
AP_INIT_TAKE1(HostnameLookups, set_hostname_lookups, NULL,
ACCESS_CONF|RSRC_CONF,
\on\ to enable, \off\ to disable reverse DNS lookups, or \double\ to
@@ -2419,9 +2432,8 @@
AP_INIT_TAKE1(ServerAdmin, set_server_string_slot,
(void *)APR_XtOffsetOf (server_rec, server_admin), RSRC_CONF,
The email address of the server administrator),
-AP_INIT_TAKE1(ServerName, set_server_string_slot,
- (void *)APR_XtOffsetOf (server_rec, server_hostname), RSRC_CONF,
- The hostname of the server),
+AP_INIT_TAKE1(ServerName, server_hostname_port, NULL, RSRC_CONF,
+ The hostname and port of the server),
AP_INIT_TAKE1(ServerSignature, set_signature_flag, NULL, OR_ALL,
En-/disable server signature (on|off|email)),
AP_INIT_TAKE1(ServerRoot, set_server_root, NULL, RSRC_CONF,
Index: server/listen.c
===
RCS file: /home/cvs/httpd-2.0/server/listen.c,v
retrieving revision 1.61
diff -u -d -b -w -u -r1.61 listen.c
--- server/listen.c 2001/08/13 04:57:34 1.61
+++ server/listen.c 2001/10/04 02:49:03
@@ -273,11 +273,10 @@
ap_listen_rec *next;
int num_open;
-/* allocate a default listener if necessary */
-if (ap_listeners == NULL) {
- alloc_listener(process, NULL, (apr_port_t)(port ? port : DEFAULT_HTTP_PORT));
-}
-
+/* Don't allocate a default listener. If we need to listen to a
+ * port, then the user needs to have a Listen directive in their
+ * config file.
+ */
num_open = 0;
for (lr = ap_listeners; lr; lr = lr-next) {
if (lr-active) {
__
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--
Re: [PATCH] Remove the Port directive.
On Wed, 3 Oct 2001, Ryan Bloom wrote: This patch completely deprectates the Port directive. The ServerName directive is now overloaded, so that admins specify the port and name on the same directive. It also makes Listen a required directive. Pay attention to that. There are no default ports with this patch. If your config doesn't have a Listen directive, the server doesn't start, and it emits an error. +1. Port vs. Listen has always been one of the things people just can't seem to figure out no matter how carefully we try to explain it. Doing it through ServerName makes it much more clear what's going on. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: [PATCH] Remove the Port directive.
On Wed, Oct 03, 2001 at 08:35:04PM -0700, Ryan Bloom wrote: The thing that concerns me the most, is that there is no default Port. If people can accept that change, then I think this is the right way to go. I think you meant there is no default listener. So what happens with this patch if you don't specify a listener? -aaron
Re: [PATCH] Remove the Port directive.
From: Ryan Bloom [EMAIL PROTECTED] Sent: Wednesday, October 03, 2001 10:24 PM This patch completely deprectates the Port directive. The ServerName directive is now overloaded, so that admins specify the port and name on the same directive. It also makes Listen a required directive. Pay attention to that. There are no default ports with this patch. If your config doesn't have a Listen directive, the server doesn't start, and it emits an error. I am a bit hesitant to commit this without some feedback, because it is a pretty major change. Before I commit this, I will update all of the docs. ++1, that's the way :) Thoughts? We've already killed BindAddress, no? If not, we need to :)
[STATUS] (apache-1.3) Wed Oct 3 23:45:07 EDT 2001
APACHE 1.3 STATUS: -*-text-*- Last modified at [$Date: 2001/10/03 18:39:38 $] Release: 1.3.21: In development - Bill Stoddard has proposed a TR soon, (tag scheduled 10/3 2330Z or thereabouts) 1.3.20: Tagged and rolled May 15, 2001. Announced May 21, 2001. 1.3.19: Tagged and rolled Feb 26, 2001. Announced Mar 01, 2001. 1.3.18: Not released. (Pulled because of an incorrect unescaping fix. t/r Feb 19, 2001) 1.3.17: Tagged and rolled Jan 26, 2001. Announced Jan 29, 2001. 1.3.16: Not released. (Pulled because of vhosting bug. t/r Jan 20, 2001) 1.3.15: Not released. (Pulled due to CVS dumping core during the tagging when it reached src/os/win32/) 1.3.14: Tagged and Rolled Oct 10, 2000. Released/announced on the 13th. 1.3.13: Not released. (Pulled in the first minutes due to a Netware build bug) 1.3.12: Tagged and rolled Feb. 23, 2000. Released/announced on the 25th. 1.3.11: Tagged and rolled Jan. 19, 2000. Released/announced on the 21st. 1.3.10: Not released. (Pulled at last minute due to a build bug in the MPE port) 1.3.9: Tagged and rolled on Aug. 16. Released and announced on 19th. 1.3.8: Not released. 1.3.7: Not released. 1.3.6: Tagged and rolled on Mar. 22. Released and announced on 24th. 1.3.5: Not released. 1.3.4: Tagged and rolled on Jan. 9. Released on 11th, announced on 12th. 1.3.3: Tagged and rolled on Oct. 7. Released on 9th, announced on 10th. 1.3.2: Tagged and rolled on Sep. 21. Announced and released on 23rd. 1.3.1: Tagged and rolled on July 19. Announced and released. 1.3.0: Tagged and rolled on June 1. Announced and released on the 6th. 2.0 : In alpha development, see httpd-2.0 repository RELEASE SHOWSTOPPERS: Security issues posted to the appropriate list. Status: backport of httpd-2.0/modules/mappers/mod_negotation.c 1.83 fixes the only remaining negotiation bugaboo. RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * htpasswd.c and htdigest.c use tmpnam()... consider using mkstemp() when available. Message-ID: [EMAIL PROTECTED] Status: * Dean's unescaping hell (unescaping the various URI components at the right time and place, esp. unescaping the host name). Message-ID: [EMAIL PROTECTED] Status: * Martin observed a core dump because a ipaddr_chain struct contains a NULL-server pointer when being dereferenced by invoking httpd -S. Message-ID: [EMAIL PROTECTED] Status: Workaround enabled. Clean solution can come after 1.3.19 * long pathnames with many components and no AllowOverride None Workaround is to define Directory / with AllowOverride None, which is something all sites should do in any case. Status: Marc was looking at it. * Ronald Tschalär's patch to mod_proxy to allow other modules to set headers too (needed by mod_auth_digest) Message-ID: [EMAIL PROTECTED] Status: Documentation that needs writing: Available Patches (Most likely, these will not be added to the official 1.3 tree, but instead should be ported to 2.0): * A rewrite of ap_unparse_uri_components() by Jeffrey W. Baker [EMAIL PROTECTED] to more fully close some segfault potential. Message-ID: Pine.LNX.4.21.0102102350060.6815-20@desktop Status: Jim +1 (for 1.3.19), Martin +0 * Patch from C. Bottelier [EMAIL PROTECTED] to run Apache without daemonizing the parent process. PR#7040 Status: fanf +1 (except it needs docs) * Andrew Ford's patch (1999/12/05) to add absolute times to mod_expires Message-ID: [EMAIL PROTECTED] Status: Martin +1, Jim +1, Ken +1 (on concept) * Raymond S Brand's path to mod_autoindex to fix the header/readme include processing so the envariables are correct for the included documents. (Actually, there are two variants in the patch message, for two different ways of doing it.) Message-ID: [EMAIL PROTECTED] Status: Martin +1(concept) * Jayaram's patch (10/27/99) for changes to mod_autoindex Problem 1: AddIcon (alttext,icon) ^^DIRECTORY^^ and AddIcon (alttext,icon) ^^BLANKICON^^ should be able to set the alternate text and icon file for any directory/blankicon in a directory listing. This was not happening because the alternate text for ^^DIRECTORY^^ and ^^BLANKICON^^ were hardcoded to DIR and respectively. Status: resolved in Apache 2.0 Problem 2: - IndexIgnore file-extension should hide the files with this file- extension in directory listings. This was NOT happening because the total filename
[STATUS] (httpd-2.0) Wed Oct 3 23:45:14 EDT 2001
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2001/10/03 17:47:50 $] Release: 2.0.25 : rolled August 29, 2001 2.0.24 : rolled August 18, 2001 2.0.23 : rolled August 9, 2001 2.0.22 : rolled July 29, 2001 2.0.21 : rolled July 20, 2001 2.0.20 : rolled July 8, 2001 2.0.19 : rolled June 27, 2001 2.0.18 : rolled May 18, 2001 2.0.17 : rolled April 17, 2001 2.0.16 : rolled April 4, 2001 2.0.15 : rolled March 21, 2001 2.0.14 : rolled March 7, 2001 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 Please consult the following STATUS files for information on related projects: * srclib/apr/STATUS * srclib/apr-util/STATUS * docs/STATUS RELEASE SHOWSTOPPERS: * Revert to a 1.3 behavior and allow a non-file request to travel through the request cycle. If any request gets to the core handler, without a flag that this r-filename was tested by dir/file_walk, then we 500 at the very end of the request cycle. This provides authors of older modules better compatibility, while still improving the security and robustness of 2.0. This does not remove the new map_to_storage hook itself, but makes it optional for some cases. Status: still need to decide where this goes, OtherBill comments... Message-ID: 065701c14526$495203b0$[EMAIL PROTECTED] we need to look at halting this in the 'default handler' case, and that implies pushing the 'handler election' into the request internal processing phase from the run request phase. * There is a bug in how we sort some hooks, at least the pre-config hook. The first time we call the hooks, they are in the correct order, but the second time, we don't sort them correctly. Currently, the modules/http/config.m4 file has been renamed to modules/http/config2.m4 to work around this problem, it should moved back when this is fixed.rbb * The Add...Filter and Set...Filter directives do not allow the administrator to order filters, beyond the order of filename (mime) extensions. It isn't clear if Set...Filter(s) should be inserted before or after the Add...Filter(s) which are ordered by sequence of filename extensions. Add...FilterByType will add to this quandry. Some sort of resolution needs to be proposed, * mod_dir should normally redirect ALL directory requests which do not include a trailing slash on the URI. However, if a notes flag is set (say, via BrowserMatch), this behavior will be disabled for non-GET requests. Status: Greg volunteers MsgId: [EMAIL PROTECTED] MsgId: [EMAIL PROTECTED] * mod_negotiation will not serve a request when an early extention is understood, but a later extention is not. e.g. if the request index.html.bak is recieved, and negotition could find the file index.html.bak.en, it still won't be served because the ap-mime-exception-list will contain index and bak, and the string index.bak doesn't match index.html.bak. Need to review the ap-mime-exception-list component by component to be allow these cases. [This could be part of a patch to allow the name index.bak in the case above to match index.html.bak.en] * mod_negotiation needs a new option or directive, something like ForceLanguagePriority, to fall back to the LanguagePriority directive instead of returning a no acceptable variant error. Status: Bill has some code in his tree that accomplishes this, and will commit it Friday after it's tested. * Usability: Sanitize the MPM config directives. MaxClients in the threaded MPM is totally misleading now as it has little to do with limiting the number of clients (it limits the number of child processes). Bill proposed nomenclature change to something like StartWorkers, MaxWorkers, etc. that could apply to most all the MPMs (with some notable exceptions). Bill would be happy with changing MaxClients to MaxServers to make it agree with the operation of the StartServers directive. * Fix the configure script to add a LoadModule directive to the default httpd.conf for any module that was compiled as a DSO. * revamp the input filter semantics, per discussions since February (and especially at the hackathon last April). Specifically, ap_get_brigade will return a brigade with *up to* a specific number of bytes, or a line of data. The read may be blocking or
Re: [Patch 1.3] mod_usertrack backport
Last chance, going once... going twice - need two +1's before I'm willing to commit this before 1.3.21 rolls. Sure looks BDSS to me. - Original Message - From: William A. Rowe, Jr. [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 02, 2001 12:19 PM Subject: [Patch 1.3] mod_usertrack backport When I was fixing mod_usertrack in 2.0, I was referring back to the 1.3 behavior and discovered two bits; 1. we waste a ton of time expanding dates that don't need expanding 2. there is still the 'millenial hack' that should be unneccessary now Any opinions on committing this patch for 1.3.21's release? I'm +1. If concensus says 'yea', I'm happy to apply, or FirstBill is welcome to beat me to it. Bill mod_usertrack.patch
RE: [PATCH] Remove the Port directive.
That's really cool.. I was just thinking about it today, and there's already a solution for it.. Especially with httpd-ssl.conf, it'd have been rally confusing for the user to configure the port number for http in 2 places.. -Madhu -Original Message- From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 03, 2001 8:38 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PATCH] Remove the Port directive. From: Ryan Bloom [EMAIL PROTECTED] Sent: Wednesday, October 03, 2001 10:24 PM This patch completely deprectates the Port directive. The ServerName directive is now overloaded, so that admins specify the port and name on the same directive. It also makes Listen a required directive. Pay attention to that. There are no default ports with this patch. If your config doesn't have a Listen directive, the server doesn't start, and it emits an error. I am a bit hesitant to commit this without some feedback, because it is a pretty major change. Before I commit this, I will update all of the docs. ++1, that's the way :) Thoughts? We've already killed BindAddress, no? If not, we need to :)
