[STATUS] (flood) Wed Mar 6 23:45:29 EST 2002
flood STATUS: -*-text-*- Last modified at [$Date: 2002/01/17 01:09:45 $] Release: milestone-04: In development milestone-03: Tagged January 16, 2002 ASF-transfer: Released July 17, 2001 milestone-02: Tagged August 13, 2001 milestone-01: Tagged July 11, 2001 (tag lost during transfer) RELEASE SHOWSTOPPERS: * Everything needs to work perfectly Other bugs that need fixing: * DNS lookup failures in any urllist cause segfault. Justin says: Wow. Why? Aaron says: Is this still happening? It's been awhile. * Misformed URLs cause a segfault. When we fix this we should make sure to print out a helpful message when this occurs. (This is not something that can be detected with a validating XML parser, unfortunately.) * iPlanet sends Content-length - there is a hack in there now to recognize it. However, all HTTP headers need to be normalized before checking their values. This isn't easy to do. Grr. * OpenSSL 0.9.6 Segfaults under high load. Upgrade to OpenSSL 0.9.6b. Aaron says: I just found a big bug that might have been causing this all along (we weren't closing ssl sockets). How can I reproduce the problem you were seeing to verify if this was the fix? * SEGVs when /tmp/.rnd doesn't exist are bad. Make it configurable and at least bomb with a good error message. (See Doug's patch.) Status: This is fixed, no? * If APR has disabled threads, flood should as well. We might want to have an enable/disable parameter that does this also, providing an error if threads are desired but not available. * flood needs to clear pools more often. With a long running test it can chew up memory very quickly. We should just bite the bullet and create/destroy/clear pools for each level of our model: farm, farmer, profile, url/request-cycle, etc. Other features that need writing: * Write robust tool (using tethereal perhaps) to take network dumps and convert them to flood's XML format. Status: Justin volunteers. Aaron had a script somewhere that is a start. * Get chunked encoding support working. Status: Justin volunteers. He got sidetracked by the httpd implementation of input filtering and never finished this. This is a stopgap until apr-serf is completed. * Maybe we should make randfile and capath runtime directives that come out of the XML, instead of autoconf parameters. * Migrate all locks to APRs new lock api. * We are using apr_os_thread_current() and getpid() in some places when what we really want is a GUID. The GUID will be used to correlate raw output data with each farmer. We may wish to print a unique ID for each of farm, farmer, profile, and url to help in postprocessing. * We are using strtol() in some places and strtoll() in others. Pick one (Aaron says strtol(), but he's not sure). * Validation of responses (known C-L, specific strings in response) Status: Justin volunteers * HTTP error codes (ie. teach it about 302s) Justin says: Yeah, this won't be with round_robin as implemented. Need a linked list-based profile where we can insert new URLs into the sequence. * Farmer (Single-thread, multiple profiles) Status: Aaron says: If you have threads, then any Farmer can be run as part of any Farm. If you don't have threads, you can currently only run one Farmer named Joe right now (this will be changed so that if you don't have threads, flood will attempt to run all Farmers in serial under one process). * Collective (Single-host, multiple farms) This is a number of Farms that have been fork()ed into child processes. * Megaconglomerate (Multiple hosts each running a collective) This is a number of Collectives running on a number of hosts, invoked via RSH/SSH or maybe even some proprietary mechanism. * Other types of urllists a) Random / Random-weighted b) Sequenced (useful with cookie propogation) c) Round-robin d) Chaining of the above strategies Status: Round-robin is complete. * Other types of reports Status: Aaron says: simple reports are functional. Justin added a new type that simply prints the approx. timestamp when the test was run, and the result as OK/FAIL; it is called easy reports (see flood_easy_reports.h). Furthermore, simple_reports and easy_reports both print out the current requesting URI line. Documentation that needs writing: * Documentation? What documentation? RTFS? Status: Justin volunteers. He'll probably use Anakia
HEADS UP regarding filter names was Re: cvs commit: httpd-2.0/server/mpm/perchild perchild.c
On Thu, Mar 07, 2002 at 09:27:17AM -, [EMAIL PROTECTED] wrote: jerenkrantz02/03/07 01:27:17 Modified:include ap_mmn.h util_filter.h modules/experimental mod_cache.c mod_case_filter.c mod_case_filter_in.c mod_charset_lite.c mod_deflate.c mod_ext_filter.c modules/filters mod_include.c modules/http http_core.c modules/metadata mod_headers.c modules/proxy proxy_ftp.c modules/test mod_bucketeer.c server core.c util_filter.c server/mpm/perchild perchild.c Log: As hinted on dev@httpd, change filter naming schemes to match our expectations of their usage. Since we've had so many issues with the filter types recently, I think it is best to do the rename that we've been hinting at. This follows from the three filter types post from rbb which gstein and wrowe agreed was goodness (so the idea has been reviewed). If you had AP_FTYPE_CONTENT, you should just use AP_FTYPE_RESOURCE. For those modules that had AP_FTYPE_HTTP_HEADER, you may want AP_FTYPE_PROTOCOL or AP_FTYPE_CONTENT_SET. For those filters that deal with raw protocol issues, they should use _PROTOCOL. For those that don't specifically deal with protocols (such as mod_deflate), they should use _CONTENT_SET. -- justin
Re: httpd-test + cvs head
On Wed, Mar 06, 2002 at 04:17:58PM -0800, Doug MacEachern wrote: to those working on filters, please make sure httpd-test/perl-framework tests are passing. i'm seeing a bunch fail at the moment, a couple with response had protocol HTTP/0.9 (headers not sent?) and various segvs: I think I've fixed most of these (by either committing fixes to httpd-test or to httpd-2.0). All of the tests except for mod_ssl are now passing for me. Failed Test Status Wstat Total Fail Failed List of Failed - ssl/http.t 11 100.00% 1 ssl/varlookup.t 722 2.78% 39, 49 However, mod_ssl is bogus. The ssl/http.t test is interesting since it causes mod_ssl to remove itself via ap_remove_output_filter() (mod_ssl.c:358). Since mod_ssl is a connection filter, our new strategy is that it can never be removed. Ooops. Since it doesn't have access to the request_rec, it can't destroy its predecessor's reference to itself. Perhaps this means we *do* need the -prev. We'll end up reading the fake request line, but the SSL input filter will still be present - since it is still referred to by r-output_filters. This will cause a segfault or other nastiness. I'm not aware how rbb wants to fix this, so I'll let him sort this out. I think tests 39, 49 failures are due to some certificate problems - the regex doesn't seem to match. Doesn't look like a filter problem. -- justin
Re: Latest CVS on Solaris 8 - configure's cache-file problems
Jeff Trawick wrote: Jim Jagielski [EMAIL PROTECTED] writes: Yep... Looks like it's no problem with 2.52. Anyone have hearburn if I adjust buildcheck.sh to make 2.52 the new requirement? at least a little, but I'm not exactly sure how much :) In the 2.0.30 timeframe a colleage was unable to get make distclean followed by a new ./configure configure to work on AIX when using autoconf 2.52. Backing down to autoconf 2.13 resolved the problem. But maybe that has been fixed problem has subsequently been fixed (some stray file left around?). I didn't see an indication of which autoconf version you had problems with. I just did cvs update and ./configure on Solaris 8 using autoconf 2.13 and so far it has gotten past the APR configure. Did configure ever work for you on that machine with autoconf 2.52? (I guess what I'd like to say is that no autoconf is perfect -- or perfectly supported by Apache+APR -- and that maybe some debugging is appropriate before we start disallowing a very common version of autoconf.) On ReliantUnix autoconf 2.52 does not work. ./buildconf gives the following error: +++ nawk: Tempcell list is curdled nawk: Source line number 7 +++ 2.13 works well. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: PROPOSAL: new directive for mod_proxy
Aaron Bannert wrote: The fix to this is to add a AllowProxy directive to the options directive. Unfortunately, I think we've run out of bits in there... Then we need more bits!!! :) Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
[Patch] Add errordir to Debian Layout.
This fixes PR10067. However, this is a fix for the symptom rather than the
cause, I think. Fundamentally, going into a system's htdocs dir and blowing
away anything called CVS is a big mistake. It doesn't make allowances for
all number of things, including the fact that the domains the server is
hosting could come straight out of cvs and access to CVS directories is
merely denied by rule, etc.
I'm going to send another patch that will need testing with non-GNU versions
of find that I think may implement a better way of doing this.
Cheers,
-Thom
Index: config.layout
===
RCS file: /home/cvspublic/httpd-2.0/config.layout,v
retrieving revision 1.9
diff -u -u -3 -r1.9 config.layout
--- config.layout 26 Feb 2002 18:41:58 - 1.9
+++ config.layout 7 Mar 2002 11:20:56 -
-306,4 +306,5
proxycachedir: ${prefix}/var/cache/apache2/proxy
infodir: ${exec_prefix}/share/info
installbuilddir: ${prefix}/etc/apache2/build
+errordir: ${data_dir}/error
/Layout
Re: [PATCH] fix alignment on shared memory
Cliff Woolley [EMAIL PROTECTED] writes: On Fri, 1 Mar 2002, Cliff Woolley wrote: Does this look right? (attached to avoid line wrapping) Hmm, no, it doesn't. :-/ Scratch that. Back to the drawing board. What was wrong with it? -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Config path brokenness
With the current HEAD (configured using --prefix=/Apps/apache2), I get the following in my ap_config_auto.h: /* Location of the config file, relative to the Apache root directory */ #define SERVER_CONFIG_FILE /Apps/apache2/conf/httpd.conf whereas in, say, 2.0.32 it reads: /* Location of the config file, relative to the Apache root directory */ #define SERVER_CONFIG_FILE conf/httpd.conf What this means is that I can no longer run the server with an alternate server root using the -d switch, something I commonly do to test running in the build tree without having to make install. It's also commonly used by users of binary builds if they want to install to a directory other than what the binary builder specified. I know this stuff's been hacked at recently, I just want to let people know it's not finished yet :) -- __ | Brian Havard | He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy! - Life of Brian | --
Re: Config path brokenness
* Brian Havard ([EMAIL PROTECTED]) wrote : With the current HEAD (configured using --prefix=/Apps/apache2), I get the following in my ap_config_auto.h: /* Location of the config file, relative to the Apache root directory */ #define SERVER_CONFIG_FILE /Apps/apache2/conf/httpd.conf whereas in, say, 2.0.32 it reads: /* Location of the config file, relative to the Apache root directory */ #define SERVER_CONFIG_FILE conf/httpd.conf What this means is that I can no longer run the server with an alternate server root using the -d switch, something I commonly do to test running in the build tree without having to make install. It's also commonly used by users of binary builds if they want to install to a directory other than what the binary builder specified. I know this stuff's been hacked at recently, I just want to let people know it's not finished yet :) use -d /path -f /path/to/conf/file Cheers, -Thom
RE: Config path brokenness
From: Brian Havard [mailto:[EMAIL PROTECTED]]
Sent: 07 March 2002 14:20
With the current HEAD (configured using --prefix=/Apps/apache2), I get the
following in my ap_config_auto.h:
/* Location of the config file, relative to the Apache root directory */
#define SERVER_CONFIG_FILE /Apps/apache2/conf/httpd.conf
whereas in, say, 2.0.32 it reads:
/* Location of the config file, relative to the Apache root directory */
#define SERVER_CONFIG_FILE conf/httpd.conf
What this means is that I can no longer run the server with an alternate
server root using the -d switch, something I commonly do to test running in
the build tree without having to make install. It's also commonly used by
users of binary builds if they want to install to a directory other than
what the binary builder specified.
I know this stuff's been hacked at recently, I just want to let people know
it's not finished yet :)
configure.in, lines 446-448:
APR_EXPAND_VAR(ap_sysconfdir, $sysconfdir)
AC_DEFINE_UNQUOTED(SERVER_CONFIG_FILE, ${ap_sysconfdir}/${progname}.conf,
[Location of the config file, relative to the Apache root directory])
Apparently $ap_sysconfdir isn't relative. We could opt for stripping
of the ap_prefix part of ap_sysconfdir if it is present.
Sander
[SEGV] mod_deflate
Hi,
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 3503)]
0x402e24b3 in strncmp (s1=0x0, s2=0x403fc7c8 text/html, n=9) at
../sysdeps/generic/strncmp.c:42
42c1 = (unsigned char) *s1++;
(gdb) bt
#0 0x402e24b3 in strncmp (s1=0x0, s2=0x403fc7c8 text/html, n=9) at
../sysdeps/generic/strncmp.c:42
#1 0x403fbfdb in deflate_out_filter (f=0x8154b18, bb=0x8154ec8) at mod_deflate.c:244
#2 0x8085a11 in ap_pass_brigade (next=0x8154b18, bb=0x8154ec8) at util_filter.c:534
#3 0x808743d in end_output_stream (r=0x81535d0) at protocol.c:941
#4 0x808748b in ap_finalize_request_protocol (r=0x81535d0) at protocol.c:961
#5 0x806b805 in ap_die (type=-2, r=0x81535d0) at http_request.c:110
#6 0x806ba8a in ap_process_request (r=0x81535d0) at http_request.c:273
#7 0x80680ec in ap_process_http_connection (c=0x8141d48) at http_core.c:287
#8 0x8083f49 in ap_run_process_connection (c=0x8141d48) at connection.c:85
#9 0x80841ef in ap_process_connection (c=0x8141d48, csd=0x8141c78) at connection.c:229
#10 0x807a466 in child_main (child_num_arg=0) at prefork.c:671
#11 0x807a51c in make_child (s=0x813fa18, slot=0) at prefork.c:707
#12 0x807a611 in startup_children (number_to_start=5) at prefork.c:784
#13 0x807a923 in ap_mpm_run (_pconf=0x80b2838, plog=0x80ea918, s=0x813fa18) at
prefork.c:1002
#14 0x807f8ad in main (argc=2, argv=0xbdac) at main.c:499
#15 0x4028826a in __libc_start_main (main=0x807f1f0 main, argc=2, ubp_av=0xbdac,
init=0x805e5b4 _init, fini=0x80957f4
_fini,
rtld_fini=0x4000daa4 _dl_fini, stack_end=0xbd9c) at
../sysdeps/generic/libc-start.c:129
(gdb) frame 1
#1 0x403fbfdb in deflate_out_filter (f=0x8154b18, bb=0x8154ec8) at mod_deflate.c:244
244 if (strncmp(r-content_type, text/html, 9)
(gdb) list
239
240 /* Some browsers might have problems with content types
241 * other than text/html, so set gzip-only-text/html
242 * (with browsermatch) for them
243 */
244 if (strncmp(r-content_type, text/html, 9)
245 apr_table_get(r-subprocess_env, gzip-only-text/html)) {
246 return ap_pass_brigade(f-next, bb);
247 }
248
Can someone tell me if r-content_type is always supposed to be pointing to something?
Sander
RE: [SEGV] mod_deflate
From: Sander Striker [mailto:[EMAIL PROTECTED]] Sent: 07 March 2002 13:56 Hi, [...] Can someone tell me if r-content_type is always supposed to be pointing to something? Nevermind, I figured it out by looking at the other modules who test r-content_type. Fix committed. Thanks, Sander
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
On Wed, 6 Mar 2002, Graham Leggett wrote: mod_accel is not proxy. It's accelarator. It can not work as usual proxy. I did not even try to implement it - Apache 1.3 is poor proxy. Squid or Oops are much better. Until recently you were not aware that the proxy had been updated - I would look at the code again before passing this judgement ;) The main reason why Squid is better than Apache is much lesser memory overhead per connection. And of course, Squid has many other proxing features - it's proxy, not webserver. For example, you pointed out some problems with Squid and content negotiation - mod_proxy doesn't have these problems. Do you mean that Squid returns cached gzipped content to client that does not send 'Accept-Encoding' ? mod_proxy 1.3.23 does the same. Would it be changed in 1.3.24 ? mod_accel can ignore client's 'Pragma: no-cache' and 'Cache-Control: no-cache'. These headers are sent if you press Reload button in Netscape or Mozilla. By default if mod_accel gets these headers then it does not look cache but send request to backend. Webmaster can set 'AccelIgnoreNoCache on' if he sure that backend did not give fresh data and such requests only overload backend. This design is broken. If the client sent a cache-control or pragma header it was because the client specifically wanted that behaviour. If this causes grief on the backend, then your backend needs to be redesigned so that it does not have such a performance hit. I live in real world and many webmasters are too. It's not always possible to redesign backend. Unfortunately while Internet boom too many brain-damaged solutions were born. Breaking the HTTP protocol isn't the fix to a broken backend. I'm considering mod_accel and backend as single entity. It does not matter for me which protocol I use for communication between them. Clients see nice HTTP protocol. Everything under /blah is proxied, except for everything under /blah/somewhere/else. Yes. But '!' is already implemented ? Yes it is. I suppose in 1.3.24 ? By the way mod_accel's syntax is more flexible - mod_accel can use regexp. *) proxy mass name-based virtual hosts with one directive on frontend: AccelPass / http://192.168.1.1/[PH] [PH] means preserve hostname, i.e. request to backend would go with original 'Host' header. mod_accel does this in one directive, mod_proxy does it in two - but the effect is the same. Should we consider adding a combined directive to mod_proxy the same way mod_accel works...? What are two mod_proxy's directives ? As far as I know mod_proxy always change 'Host' header. Use the ProxyPreserveHost option. I suppose in 1.3.24 ? mod_accel can send part of answer to client even backend has not sent whole answer. But even in this case slow client never block backend - I use nonblocking operations and select(). Would it be possible with mod_cache ? The idea behind mod_cache was to separate the send threads from the receive thread. This means that if a response is half-way downloaded, and a new request comes in, the new request will be served from the half-cached half-downloaded file, and not from a new request. When the original request is finished, the backend is released, and the receive threads carry on regardless. Would it be work in prefork MPM ? Both busy locks and limiting concurrent connections can be useful in a normal Apache server using mod_cgi, or one of the Java servlet connectors. Adding this to proxy means it can only be used in proxy - which is a bad idea. Probably but Apache 1.3.x has not such module and I needed it too much in mod_accel. You should have created a separate module for this, and run it alongside mod_accel. This can still be done though. I did not use mod_cgi and Java. This is the job of mod_rewrite. mod_rewrite can not do it. Then rewrite should be patched to do it. Your phrase is like 'mod_rewrite should be patched to do some SSI job' mod_rewrite works with URLs and filenames only. It can not change content. mod_randban changes content on the fly. Igor Sysoev
Re: proxy busted
Ryan Bloom [EMAIL PROTECTED] writes: But I guess the problem is a misuse of r-proto_input_filters vs. r-input_filters on this path??? Nope. This problem is in the proxy itself. That's what I meant... I had tried half of your fix with no luck (and worse, no understanding :) ). Make_fake_proxy_req isn't setting r-proto_input_filters or r-proto_output_filters. That means that the rest of the logic is wrong. I'll try to get around to fixing this tonight, but I may not get to it. Thanks for fixing it! -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0 config.layout
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote :
aaron 02/03/07 06:26:07
Modified:.config.layout
Log:
Add a missing errordir entry in the Debian config.layout.
PR: 10067
Obtained from: Dirk-Jan Faber [EMAIL PROTECTED]
Unfortunately that fix isn't quite correct, as it would put the errordir as
/error .
Correction attached.
Cheers,
-Thom
Index: config.layout
===
RCS file: /home/cvspublic/httpd-2.0/config.layout,v
retrieving revision 1.10
diff -u -u -r1.10 config.layout
--- config.layout 7 Mar 2002 14:26:07 - 1.10
+++ config.layout 7 Mar 2002 14:42:22 -
@@ -306,5 +306,5 @@
proxycachedir: ${prefix}/var/cache/apache2/proxy
infodir: ${exec_prefix}/share/info
installbuilddir: ${prefix}/etc/apache2/build
-errordir: ${prefix}/error
+errordir: ${data_dir}/error
/Layout
RE: httpd-test + cvs head
On Wed, Mar 06, 2002 at 04:17:58PM -0800, Doug MacEachern wrote: to those working on filters, please make sure httpd-test/perl-framework tests are passing. i'm seeing a bunch fail at the moment, a couple with response had protocol HTTP/0.9 (headers not sent?) and various segvs: I think I've fixed most of these (by either committing fixes to httpd-test or to httpd-2.0). All of the tests except for mod_ssl are now passing for me. Failed Test Status Wstat Total Fail Failed List of Failed - ssl/http.t 11 100.00% 1 ssl/varlookup.t 722 2.78% 39, 49 However, mod_ssl is bogus. The ssl/http.t test is interesting since it causes mod_ssl to remove itself via ap_remove_output_filter() (mod_ssl.c:358). Since mod_ssl is a connection filter, our new strategy is that it can never be removed. Ooops. Since it doesn't have access to the request_rec, HUH? Where did you get that connection filters can never be removed. That was never said anywhere. You must be able to remove any filter. it can't destroy its predecessor's reference to itself. Perhaps this means we *do* need the -prev. Damn, that is a sticky wicket. My thought right now is that ap_pass_brigade and ap_get_brigade automatically add the request_rec pointer to the filter structure when they are called. We'll end up reading the fake request line, but the SSL input filter will still be present - since it is still referred to by r-output_filters. This will cause a segfault or other nastiness. I'm not aware how rbb wants to fix this, so I'll let him sort this out. Ryan
RE: Config path brokenness
* Brian Havard ([EMAIL PROTECTED]) wrote : With the current HEAD (configured using --prefix=/Apps/apache2), I get the following in my ap_config_auto.h: /* Location of the config file, relative to the Apache root directory */ #define SERVER_CONFIG_FILE /Apps/apache2/conf/httpd.conf whereas in, say, 2.0.32 it reads: /* Location of the config file, relative to the Apache root directory */ #define SERVER_CONFIG_FILE conf/httpd.conf What this means is that I can no longer run the server with an alternate server root using the -d switch, something I commonly do to test running in the build tree without having to make install. It's also commonly used by users of binary builds if they want to install to a directory other than what the binary builder specified. I know this stuff's been hacked at recently, I just want to let people know it's not finished yet :) use -d /path -f /path/to/conf/file That's not good enough Thom. The -d must be able to work on its own. That's why we allow relative paths for just about everything. Ryan
RE: proxy busted
Ryan Bloom [EMAIL PROTECTED] writes: But I guess the problem is a misuse of r-proto_input_filters vs. r-input_filters on this path??? Nope. This problem is in the proxy itself. That's what I meant... I had tried half of your fix with no luck (and worse, no understanding :) ). Make_fake_proxy_req isn't setting r-proto_input_filters or r-proto_output_filters. That means that the rest of the logic is wrong. I'll try to get around to fixing this tonight, but I may not get to it. Thanks for fixing it! Glad I got to it last night. Now, is there anything I can do to help people understand the recent changes better? Ryan
Re: Why do we have NONBLOCK bucket reads? (or, I want poll for buckets)
On Wed, Mar 06, 2002 at 11:42:11PM -0800, Greg Stein wrote: apr_bucket_read(NONBLOCK) if (got_nothing) do_some_work flush_some_buffers apr_bucket_read(BLOCK) process_buckets() In other words, you could see if you have some work to do. If not, then you go off and flush out other stuff that was pending. (that is: take advantage of idle time) Once you're done with the work, then you go ahead and block to get more work. You are correct, and this pattern is used twice only in mod_include. It seems to me that this pattern would tend to double the amount of system calls to read, while only being successful with fast clients. I would have to do some testing, but I suspect that we're not actually improving data processing/response time but are instead increasing system time. Just a hunch though... -aaron
RE: Why do we have NONBLOCK bucket reads? (or, I want poll for buckets)
On Wed, Mar 06, 2002 at 11:42:11PM -0800, Greg Stein wrote: apr_bucket_read(NONBLOCK) if (got_nothing) do_some_work flush_some_buffers apr_bucket_read(BLOCK) process_buckets() In other words, you could see if you have some work to do. If not, then you go off and flush out other stuff that was pending. (that is: take advantage of idle time) Once you're done with the work, then you go ahead and block to get more work. You are correct, and this pattern is used twice only in mod_include. It seems to me that this pattern would tend to double the amount of system calls to read, while only being successful with fast clients. I would have to do some testing, but I suspect that we're not actually improving data processing/response time but are instead increasing system time. Just a hunch though... It depends on what you are doing in between the first read and the second. The original conversation around filters only discussed non-blocking in terms of being able to pass the brigade faster. So, the conversation was always: apr_bucket_read(NON_BLOCK) If (got_nothing) Do some stuff Ap_pass_brigade() Apr_bucket_read(BLOCK) If you are passing a bunch of data to be written to the network, then the streaming effect outweighs the system time cost, because the user feels like they are getting the data faster. Of course, that logic doesn't work if you aren't putting a pass_briade inside the if clause. :-) Ryan
Re: Config path brokenness
* Ryan Bloom ([EMAIL PROTECTED]) wrote : * Brian Havard ([EMAIL PROTECTED]) wrote : it's not finished yet :) use -d /path -f /path/to/conf/file That's not good enough Thom. The -d must be able to work on its own. That's why we allow relative paths for just about everything. I agree completely. What my message should have said was this gets you what you need for the time being, while I work on a real fix. My apologies for this. I am working on getting a real fix in. Hopefully I should have it nailled down in the next hour or so. Cheers, -Thom
Re: [Patch] Add errordir to Debian Layout.
On Thu, Mar 07, 2002 at 11:30:05AM +, Thom May wrote: This fixes PR10067. However, this is a fix for the symptom rather than the cause, I think. Fundamentally, going into a system's htdocs dir and blowing away anything called CVS is a big mistake. It doesn't make allowances for all number of things, including the fact that the domains the server is hosting could come straight out of cvs and access to CVS directories is merely denied by rule, etc. I'm going to send another patch that will need testing with non-GNU versions of find that I think may implement a better way of doing this. Cheers, -Thom Sorry Thom, I didn't see this post until just now. (I saw the bug report first and just went to fix that. :) I did see your later post and did note you in the CHANGES. Thanks for the patch. -aaron
Re: Config path brokenness
On Thu, Mar 07, 2002 at 01:37:28PM +0100, Sander Striker wrote:
I know this stuff's been hacked at recently, I just want to let people know
it's not finished yet :)
Yes, that was me. :)
configure.in, lines 446-448:
APR_EXPAND_VAR(ap_sysconfdir, $sysconfdir)
AC_DEFINE_UNQUOTED(SERVER_CONFIG_FILE, ${ap_sysconfdir}/${progname}.conf,
[Location of the config file, relative to the Apache root directory])
Apparently $ap_sysconfdir isn't relative. We could opt for stripping
of the ap_prefix part of ap_sysconfdir if it is present.
+1
If nobody gets to it first, I'll create another m4 macro for striping
off $prefix from $var. If $prefix isn't a prefix on $var then it won't
change $var.
perhaps APR_UNPREPEND_VAR(var, $prefix) ?
-aaron
Re: Config path brokenness
* Thom May ([EMAIL PROTECTED]) wrote :
* Ryan Bloom ([EMAIL PROTECTED]) wrote :
* Brian Havard ([EMAIL PROTECTED]) wrote :
it's not finished yet :)
use -d /path -f /path/to/conf/file
That's not good enough Thom. The -d must be able to work on its own.
That's why we allow relative paths for just about everything.
I agree completely. What my message should have said was this gets you what
you need for the time being, while I work on a real fix.
My apologies for this. I am working on getting a real fix in.
Hopefully I should have it nailled down in the next hour or so.
Cheers,
-Thom
By way of replying to myself, here's the patches.
It creates a new macro in ac_common.m4 in apr, APR_STRIP_PREFIX, and uses
that to generate a relative path.
This is integrated into confgure.in to give a relative path for
sysconfigdir.
Cheers,
-Thom
Index: build/apr_common.m4
===
RCS file: /home/cvspublic/apr/build/apr_common.m4,v
retrieving revision 1.23
diff -u -u -3 -r1.23 apr_common.m4
--- build/apr_common.m4 28 Feb 2002 02:54:01 - 1.23
+++ build/apr_common.m4 7 Mar 2002 15:34:27 -
@@ -577,3 +577,16 @@
$1=$cur
])
+dnl removes ${prefix} from the valuable of a variable
+dnl giving a relative path rather than an absolute one.
+dnl
+dnl Example:
+dnl
+dnl foo=${prefix}/bar
+dnl APR_STRIP_PREFIX(baz, $foo)
+dnl$baz is now bar
+AC_DEFUN(APR_STRIP_PREFIX,[
+abs=$2
+rel=`echo $abs|sed -e 's#${prefix}/\(.*\)#\1#' -e 's#^/\(.*\)#\1#'`
+$1=$rel
+])
--
Index: configure.in
===
RCS file: /home/cvspublic/httpd-2.0/configure.in,v
retrieving revision 1.207
diff -u -u -3 -r1.207 configure.in
--- configure.in7 Mar 2002 00:23:30 - 1.207
+++ configure.in7 Mar 2002 15:33:43 -
@@ -443,8 +443,8 @@
APR_EXPAND_VAR(ap_prefix, $prefix)
AC_DEFINE_UNQUOTED(HTTPD_ROOT, ${ap_prefix},
[Root directory of the Apache install area])
-APR_EXPAND_VAR(ap_sysconfdir, $sysconfdir)
-AC_DEFINE_UNQUOTED(SERVER_CONFIG_FILE, ${ap_sysconfdir}/${progname}.conf,
+APR_STRIP_PREFIX(rel_sysconfdir, $sysconfdir)
+AC_DEFINE_UNQUOTED(SERVER_CONFIG_FILE, ${rel_sysconfdir}/${progname}.conf,
[Location of the config file, relative to the Apache root directory])
AC_DEFINE_UNQUOTED(APACHE_MPM_DIR, $MPM_DIR,
[Location of the source for the current MPM])
Re: Config path brokenness
On Thu, Mar 07, 2002 at 03:38:59PM +, Thom May wrote:
By way of replying to myself, here's the patches.
It creates a new macro in ac_common.m4 in apr, APR_STRIP_PREFIX, and uses
that to generate a relative path.
This is integrated into confgure.in to give a relative path for
sysconfigdir.
Cheers,
-Thom
Index: build/apr_common.m4
===
RCS file: /home/cvspublic/apr/build/apr_common.m4,v
retrieving revision 1.23
diff -u -u -3 -r1.23 apr_common.m4
--- build/apr_common.m4 28 Feb 2002 02:54:01 - 1.23
+++ build/apr_common.m4 7 Mar 2002 15:34:27 -
-577,3 +577,16
$1=$cur
])
+dnl removes ${prefix} from the valuable of a variable
+dnl giving a relative path rather than an absolute one.
+dnl
+dnl Example:
+dnl
+dnl foo=${prefix}/bar
+dnl APR_STRIP_PREFIX(baz, $foo)
+dnl $baz is now bar
+AC_DEFUN(APR_STRIP_PREFIX,[
+abs=$2
+rel=`echo $abs|sed -e 's#${prefix}/\(.*\)#\1#' -e 's#^/\(.*\)#\1#'`
+$1=$rel
+])
I was thinking something more generic:
dnl APR_UNPREPEND_VAR(var, $to_strip)
dnl
AC_DEFUN(APR_UNPREPEND_VAR(,[
orig=$$1
to_strip=$2
rel=`echo $orig|sed -e s#^${to_strip}##`
$1=$rel
])
(I have no idea if that would work, or if you can do orig=$$1)
-aaron
Re: PROPOSAL: new directive for mod_proxy
On Thu, 7 Mar 2002, Graham Leggett wrote: Aaron Bannert wrote: The fix to this is to add a AllowProxy directive to the options directive. Unfortunately, I think we've run out of bits in there... Then we need more bits!!! :) Yes, we could add more bits in 2.0. But my question remains the same as it always has been: What is the advantage of adding something to Options rather than having an independent directive? The disadvantage is that nobody understands how to use the Options directive. A quick search on google groups could find you literally hundreds of examples of people using Options incorrectly, and hundreds more examples of people who can't get SSI or CGI to work because they don't understand how to use Options. Joshua.
Re: Config path brokenness
Aaron Bannert wrote: If nobody gets to it first, I'll create another m4 macro for striping off $prefix from $var. If $prefix isn't a prefix on $var then it won't change $var. perhaps APR_UNPREPEND_VAR(var, $prefix) ? APR_STRIP_PREFIX_VAR ? :) -- === 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: PROPOSAL: new directive for mod_proxy
On Thu, Mar 07, 2002 at 10:57:21AM -0500, Joshua Slive wrote: Yes, we could add more bits in 2.0. But my question remains the same as it always has been: What is the advantage of adding something to Options rather than having an independent directive? The disadvantage is that nobody understands how to use the Options directive. A quick search on google groups could find you literally hundreds of examples of people using Options incorrectly, and hundreds more examples of people who can't get SSI or CGI to work because they don't understand how to use Options. +1 on adding new directives and not extending Options, especially since this directive only relates to mod_proxy. -aaron
Re: PROPOSAL: new directive for mod_proxy
Aaron Bannert wrote: +1 on adding new directives and not extending Options, especially since this directive only relates to mod_proxy. +1 as well -- === 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: Config path brokenness
* Aaron Bannert ([EMAIL PROTECTED]) wrote :
On Thu, Mar 07, 2002 at 03:38:59PM +, Thom May wrote:
I was thinking something more generic:
dnl APR_UNPREPEND_VAR(var, $to_strip)
dnl
AC_DEFUN(APR_UNPREPEND_VAR(,[
orig=$$1
to_strip=$2
rel=`echo $orig|sed -e s#^${to_strip}##`
$1=$rel
])
I have something similar now working, but with one exception - instead of
passing a variable to strip, you just pass the name of the variable.
-Thom
Index: build/apr_common.m4
===
RCS file: /home/cvspublic/apr/build/apr_common.m4,v
retrieving revision 1.23
diff -u -u -3 -r1.23 apr_common.m4
--- build/apr_common.m4 28 Feb 2002 02:54:01 - 1.23
+++ build/apr_common.m4 7 Mar 2002 16:55:57 -
@@ -577,3 +577,17 @@
$1=$cur
])
+dnl removes ${to_strip} from the value of a variable
+dnl giving a relative path rather than an absolute one.
+dnl
+dnl Example:
+dnl
+dnl foo=${prefix}/bar
+dnl APR_UNPREPEND_VAR(baz, $foo, prefix)
+dnl$baz is now bar
+AC_DEFUN(APR_UNPREPEND_VAR,[
+to_strip=\${$3}
+abs=$2
+rel=`echo $abs|sed -e s#$to_strip/\(.*\)#\1# -e s#^/\(.*\)#\1#`
+$1=$rel
+])
Index: configure.in
===
RCS file: /home/cvspublic/httpd-2.0/configure.in,v
retrieving revision 1.207
diff -u -u -3 -r1.207 configure.in
--- configure.in7 Mar 2002 00:23:30 - 1.207
+++ configure.in7 Mar 2002 16:54:18 -
@@ -443,8 +443,8 @@
APR_EXPAND_VAR(ap_prefix, $prefix)
AC_DEFINE_UNQUOTED(HTTPD_ROOT, ${ap_prefix},
[Root directory of the Apache install area])
-APR_EXPAND_VAR(ap_sysconfdir, $sysconfdir)
-AC_DEFINE_UNQUOTED(SERVER_CONFIG_FILE, ${ap_sysconfdir}/${progname}.conf,
+APR_UNPREPEND_VAR(rel_sysconfdir, $sysconfdir, prefix)
+AC_DEFINE_UNQUOTED(SERVER_CONFIG_FILE, ${rel_sysconfdir}/${progname}.conf,
[Location of the config file, relative to the Apache root directory])
AC_DEFINE_UNQUOTED(APACHE_MPM_DIR, $MPM_DIR,
[Location of the source for the current MPM])
Writing apache module in C++
I am working on a project to write an apache module in C++. Do I need
anything else other than wrapping MODULE_VAR_EXPORT in extern C{}?
Thanks!
--
Wei Weng
Network Software Engineer
KenCast Inc.
Re: Writing apache module in C++
On Thu, Mar 07, 2002 at 12:06:04PM -0500, Wei Weng wrote:
I am working on a project to write an apache module in C++. Do I need
anything else other than wrapping MODULE_VAR_EXPORT in extern C{}?
This is the server development list. Your question would be better
asked on the module authors mailing list ([EMAIL PROTECTED]).
Send a message to [EMAIL PROTECTED] to subscribe.
-aaron
Re: Writing apache module in C++
On Thu, Mar 07, 2002 at 09:42:36AM -0800, Aaron Bannert wrote: This is the server development list. Your question would be better asked on the module authors mailing list ([EMAIL PROTECTED]). Send a message to [EMAIL PROTECTED] to subscribe. Oop, looks like you already made it over there. Thanks! -a
RE: Code questions
server/config.c:396 return !!(cmd-limited (AP_METHOD_BIT methnum)); ^^ Is that a typo or intentional? It's intentional. This line always sparks a VERY large debate. The reason for it is that it is the only way to ensure that you have a 1 or 0 result. By negating twice, the first negation always takes the result to 0 or 1, and second always gives the opposite result. server/core.c:661 AP_DECLARE(const char *) ap_document_root(request_rec *r) /* Don't use this! */ If we shouldn't use it, why is it still here? Because people are lazy and most people didn't realize that comment existed. If nobody is using that function, remove it. server/core.c:691 /* Should probably just get rid of this... the only code that cares is * part of the core anyway (and in fact, it isn't publicised to other * modules). */ Read the comment. Check to make sure nobody uses it, and remove it if nobody does. server/listen.c:320 /*free(lr);*/ Can this go? Was there a future purpose to this call, or was it just old code commented out? It most likely highlights a memory leak more than anything else. These structures use to be malloc'ed, and free'd at the correct times. Now we use palloc to allocate them. I would bet that the free was left so that somebody would remember to look for the leak. Ryan
RE: Code questions
From: Ryan Bloom [mailto:[EMAIL PROTECTED]]
Sent: 07 March 2002 19:58
server/config.c:396
return !!(cmd-limited (AP_METHOD_BIT methnum));
^^
Is that a typo or intentional?
It's intentional. This line always sparks a VERY large debate.
Then why didn't any one leave a nice comment behind so that this
doesn't happen again? ;)
The reason for it is that it is the only way to ensure that you have a 1 or
0 result. By negating twice, the first negation always takes the result
to 0 or 1, and second always gives the opposite result.
It's not exactly the only way. There are two more:
1)return (cmd-limited (AP_METHOD_BIT methnum)) ? 1 : 0;
2)return (cmd-limited (AP_METHOD_BIT methnum)) != 0;
And method 3, this entire block:
/*
* A method number either hardcoded into apache or
* added by a module and registered.
*/
if (methnum != M_INVALID) {
return (cmd-limited (AP_METHOD_BIT methnum)) ? 1 : 0;
}
return 0; /* not found */
can be written as:
/*
* A method number either hardcoded into apache or
* added by a module and registered.
*/
return (methnum != M_INVALID
(cmd-limited (AP_METHOD_BIT methnum)));
If noone steps up I'll change it to method 1, since that is
most clear to read for everyone I think.
server/core.c:661
AP_DECLARE(const char *) ap_document_root(request_rec *r) /* Don't use this! */
If we shouldn't use it, why is it still here?
Because people are lazy and most people didn't realize that comment
existed. If nobody is using that function, remove it.
Okay, thanks for the heads up.
server/core.c:691
/* Should probably just get rid of this... the only code that cares is
* part of the core anyway (and in fact, it isn't publicised to other
* modules).
*/
Read the comment.
Check to make sure nobody uses it, and remove it if nobody does.
Ok.
server/listen.c:320
/*free(lr);*/
Can this go? Was there a future purpose to this call,
or was it just old code commented out?
It most likely highlights a memory leak more than anything else. These
structures use to be malloc'ed, and free'd at the correct times. Now we
use palloc to allocate them. I would bet that the free was left so that
somebody would remember to look for the leak.
Consider the line torched.
Ryan
Thanks,
Sander
Re: Writing apache module in C++
On Thu, 7 Mar 2002, Wei Weng wrote:
I am working on a project to write an apache module in C++. Do I need
anything else other than wrapping MODULE_VAR_EXPORT in extern C{}?
Thanks!
I have been working on an Apache-2.0 project which allows you to implement
modules in C++ without any of this funniness (simply build your class into
an so) if you or anyone is interested: http://modcplusplus.sourceforge.net
sterling
Copyright year bumping
Hi, Should we bump the copyright year on all the files? Anyone have a script handy? Sander
Torching ap_document_root, WAS: RE: Code questions
From: Sander Striker [mailto:[EMAIL PROTECTED]]
Sent: 07 March 2002 20:48
server/core.c:661
AP_DECLARE(const char *) ap_document_root(request_rec *r) /* Don't use this! */
If we shouldn't use it, why is it still here?
Because people are lazy and most people didn't realize that comment
existed. If nobody is using that function, remove it.
Okay, thanks for the heads up.
modules/ssl/ssl_engine_vars.c:158:result = (char *)ap_document_root(r);
modules/mappers/mod_rewrite.c:1255:if ((ccp = ap_document_root(r)) !=
NULL) {
modules/mappers/mod_rewrite.c:1552:if ((ccp = ap_document_root(r)) !=
NULL) {
modules/mappers/mod_rewrite.c:3492:result = ap_document_root(r);
server/util_script.c:278:apr_table_addn(e, DOCUMENT_ROOT, ap_document_root(r));
/* Apache */
Ofcourse there are always places where such a function is used...
Question is now, are they legit? Should they be changed?
Sander
RE: Torching ap_document_root, WAS: RE: Code questions
server/core.c:661
AP_DECLARE(const char *) ap_document_root(request_rec *r) /*
Don't
use this! */
If we shouldn't use it, why is it still here?
Because people are lazy and most people didn't realize that comment
existed. If nobody is using that function, remove it.
Okay, thanks for the heads up.
modules/ssl/ssl_engine_vars.c:158:result = (char
*)ap_document_root(r);
modules/mappers/mod_rewrite.c:1255:if ((ccp =
ap_document_root(r)) != NULL) {
modules/mappers/mod_rewrite.c:1552:if ((ccp =
ap_document_root(r)) != NULL) {
modules/mappers/mod_rewrite.c:3492:result =
ap_document_root(r);
server/util_script.c:278:apr_table_addn(e, DOCUMENT_ROOT,
ap_document_root(r)); /* Apache */
Ofcourse there are always places where such a function is used...
Question is now, are they legit? Should they be changed?
Having looked at the code now. MO is, yes they are legit. The code
reaches into a core private structure to grab the conf-document_root
variable. I don't want modules doing that themselves.
Ryan
Re: cvs commit: apache-1.3/src/modules/proxy mod_proxy.h proxy_cache.c proxy_ftp.c proxy_http.c proxy_util.c
[EMAIL PROTECTED] wrote: minfrin 02/02/20 22:03:09 Log: When proxy enabled a slow frontend client to read from an expensive backend server, it would wait until it had delivered the response to the slow frontend client completely before closing the backend connection. The backend connection is now closed as soon as the last byte is read from it, freeing up resources that would have been tied up unnecessarily. The proxy code read chunks from the backend server in a hardcoded amount of 8k. The existing ProxyReceiveBufferSize parameter has been overloaded to specify the size of this buffer. Just noticed.. you need to include the 'Submitted by' and 'reviewed by' lines in the CVS log when committing someone else's work. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp!
Torching ap_response_code_string, WAS: RE: Code questions
From: Sander Striker [mailto:[EMAIL PROTECTED]]
Sent: 07 March 2002 20:48
server/core.c:691
/* Should probably just get rid of this... the only code that cares is
* part of the core anyway (and in fact, it isn't publicised to other
* modules).
*/
Read the comment.
Check to make sure nobody uses it, and remove it if nobody does.
Ok.
modules/http/http_protocol.c:1923:if ((custom_response =
ap_response_code_string(r, idx))) {
modules/http/http_request.c:102:char *custom_response = ap_response_code_string(r,
error_index);
Two places where it is used. Suggestions?
Sander
RE: Torching ap_document_root, WAS: RE: Code questions
From: Ryan Bloom [mailto:[EMAIL PROTECTED]]
Sent: 07 March 2002 20:49
server/core.c:661
AP_DECLARE(const char *) ap_document_root(request_rec *r) /*
Don't
use this! */
If we shouldn't use it, why is it still here?
Because people are lazy and most people didn't realize that comment
existed. If nobody is using that function, remove it.
Okay, thanks for the heads up.
modules/ssl/ssl_engine_vars.c:158:result = (char
*)ap_document_root(r);
modules/mappers/mod_rewrite.c:1255:if ((ccp =
ap_document_root(r)) != NULL) {
modules/mappers/mod_rewrite.c:1552:if ((ccp =
ap_document_root(r)) != NULL) {
modules/mappers/mod_rewrite.c:3492:result =
ap_document_root(r);
server/util_script.c:278:apr_table_addn(e, DOCUMENT_ROOT,
ap_document_root(r)); /* Apache */
Ofcourse there are always places where such a function is used...
Question is now, are they legit? Should they be changed?
Having looked at the code now. MO is, yes they are legit. The code
reaches into a core private structure to grab the conf-document_root
variable. I don't want modules doing that themselves.
So the /* don't use this! */ comment should go?
Ryan
Sander
Re: Torching ap_document_root
On Thu, Mar 07, 2002 at 09:23:02PM +0100, Sander Striker wrote: ... server/core.c:661 AP_DECLARE(const char *) ap_document_root(request_rec *r) /* Don't use this! */ If we shouldn't use it, why is it still here? ... Having looked at the code now. MO is, yes they are legit. The code reaches into a core private structure to grab the conf-document_root variable. I don't want modules doing that themselves. So the /* don't use this! */ comment should go? I would say rewrite it to be something like: Modules shouldn't be worried about the document root. If you need to call this function, then you should ask yourself why. Modules should be more concerned with r-uri and r-filename. Cheers, -g -- Greg Stein, http://www.lyra.org/
warnings, fyi
mod_disk_cache.c: In function `remove_entity': mod_disk_cache.c:436: warning: unused variable `obj' mod_disk_cache.c: In function `write_body': mod_disk_cache.c:599: warning: unused variable `info' mod_disk_cache.c: In function `set_cache_gcint': mod_disk_cache.c:666: warning: unused variable `conf' mod_disk_cache.c: In function `set_cache_exchk': mod_disk_cache.c:707: warning: unused variable `conf' mod_disk_cache.c: In function `set_cache_minetm': mod_disk_cache.c:731: warning: unused variable `conf' mod_disk_cache.c: In function `set_cache_gctime': mod_disk_cache.c:739: warning: unused variable `conf' mod_disk_cache.c: In function `add_cache_gcclean': mod_disk_cache.c:747: warning: unused variable `conf' mod_disk_cache.c: In function `add_cache_gcclnun': mod_disk_cache.c:755: warning: unused variable `conf' mod_disk_cache.c: In function `set_cache_maxgcmem': mod_disk_cache.c:763: warning: unused variable `conf' mod_disk_cache.c: At top level: mod_disk_cache.c:430: warning: `remove_url' defined but not used mod_mem_cache.c: In function `cleanup_cache_object': mod_mem_cache.c:150: warning: passing arg 1 of `free' discards qualifiers from pointer target type mod_mem_cache.c:153: warning: passing arg 1 of `free' discards qualifiers from pointer target type mod_mem_cache.c:156: warning: passing arg 1 of `free' discards qualifiers from pointer target type mod_mem_cache.c:159: warning: passing arg 1 of `free' discards qualifiers from pointer target type -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: warnings, fyi
I just checked in some changes to mod_mem_cache, so hopefully those warning go away now... Bill - Original Message - From: Cliff Woolley [EMAIL PROTECTED] To: Bill Stoddard [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 07, 2002 5:37 PM Subject: warnings, fyi mod_disk_cache.c: In function `remove_entity': mod_disk_cache.c:436: warning: unused variable `obj' mod_disk_cache.c: In function `write_body': mod_disk_cache.c:599: warning: unused variable `info' mod_disk_cache.c: In function `set_cache_gcint': mod_disk_cache.c:666: warning: unused variable `conf' mod_disk_cache.c: In function `set_cache_exchk': mod_disk_cache.c:707: warning: unused variable `conf' mod_disk_cache.c: In function `set_cache_minetm': mod_disk_cache.c:731: warning: unused variable `conf' mod_disk_cache.c: In function `set_cache_gctime': mod_disk_cache.c:739: warning: unused variable `conf' mod_disk_cache.c: In function `add_cache_gcclean': mod_disk_cache.c:747: warning: unused variable `conf' mod_disk_cache.c: In function `add_cache_gcclnun': mod_disk_cache.c:755: warning: unused variable `conf' mod_disk_cache.c: In function `set_cache_maxgcmem': mod_disk_cache.c:763: warning: unused variable `conf' mod_disk_cache.c: At top level: mod_disk_cache.c:430: warning: `remove_url' defined but not used mod_mem_cache.c: In function `cleanup_cache_object': mod_mem_cache.c:150: warning: passing arg 1 of `free' discards qualifiers from pointer target type mod_mem_cache.c:153: warning: passing arg 1 of `free' discards qualifiers from pointer target type mod_mem_cache.c:156: warning: passing arg 1 of `free' discards qualifiers from pointer target type mod_mem_cache.c:159: warning: passing arg 1 of `free' discards qualifiers from pointer target type -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-2.0/server protocol.c
On Thu, Mar 07, 2002 at 10:08:46PM -, [EMAIL PROTECTED] wrote: gregames02/03/07 14:08:46 Modified:include http_protocol.h server protocol.c Log: ap_rgetline: fix folding and partial line handling on ebcdic boxes. The normal case worked OK, but due to the recursion and multiple exit points, input bytes could go thru charset translation multiple times or not at all. Suggested by: Justin Erenkrantz Very cool. -- justin
Re: warnings, fyi
On Thu, 7 Mar 2002, Bill Stoddard wrote: I just checked in some changes to mod_mem_cache, so hopefully those warning go away now... I'll double check, but the commit looked right on target. Thanks! --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Compiling apache2 against glibc 2.2.5
Glibc 2.2.5 was compiled with gcc3. This is supposed to be allowable with glibc 2.2.5, since it was unsupported prior. Does anyone know of any issues doing this? My binaries are portable, and that doesn't seem to be a problem. I'm trying to gather information as I continue to try to chase down the php4.2-dev + apache2 issue on this target platform. TIA. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: [EMAIL PROTECTED] It is the part of a good shepherd to shear his flock, not to skin it. Latin Proverb
[PATCH] Re: Apache 2.0.34-dev Sends Wrong Content-Type on 404
On Thu, 7 Mar 2002, Jerry Baker wrote:
Apache 2.0.34-dev pulled from CVS today is sending text/plain as the
content-type on 404 responses. See example below:
HTTP/1.1 404 Not Found
Date: Thu, 07 Mar 2002 21:23:10 GMT
Server: Apache/2.0.34-dev (Win32)
Vary: accept-language
Content-Length: 794
Connection: close
Content-Type: text/plain; charset=ISO-8859-1
This, or course, makes the 404 response appear as a screen full of HTML
code instead of how it should.
I think this is a general problem with get_canned_error_string - something
like the following should fix that
Index: modules/http/http_protocol.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/http/http_protocol.c,v
retrieving revision 1.393
diff -u -r1.393 http_protocol.c
--- modules/http/http_protocol.c4 Mar 2002 05:54:44 - 1.393
+++ modules/http/http_protocol.c8 Mar 2002 01:42:06 -
-1618,6 +1618,7
apr_pool_t *p = r-pool;
const char *error_notes, *h1, *s1;
+r-content_type = text/html;
switch (status) {
case HTTP_MOVED_PERMANENTLY:
case HTTP_MOVED_TEMPORARILY:
Re: [PATCH] Re: Apache 2.0.34-dev Sends Wrong Content-Type on 404
On Thu, Mar 07, 2002 at 05:43:20PM -0800, John Sterling wrote:
I think this is a general problem with get_canned_error_string - something
like the following should fix that
Index: modules/http/http_protocol.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/http/http_protocol.c,v
retrieving revision 1.393
diff -u -r1.393 http_protocol.c
--- modules/http/http_protocol.c 4 Mar 2002 05:54:44 - 1.393
+++ modules/http/http_protocol.c 8 Mar 2002 01:42:06 -
-1618,6 +1618,7
apr_pool_t *p = r-pool;
const char *error_notes, *h1, *s1;
+r-content_type = text/html;
switch (status) {
case HTTP_MOVED_PERMANENTLY:
case HTTP_MOVED_TEMPORARILY:
John posted this patch awhile ago. I'm +1 and will commit in 24 hours
unless someone speaks up with a reason not to.
-aaron
Re: [PATCH] Re: Apache 2.0.34-dev Sends Wrong Content-Type on 404
[EMAIL PROTECTED] wrote: I think this is a general problem with get_canned_error_string - something like the following should fix that This patch does not appear to remedy the problem here on Win32. -- Jerry Baker
Re: [PATCH] Re: Apache 2.0.34-dev Sends Wrong Content-Type on 404
[EMAIL PROTECTED] wrote: I think this is a general problem with get_canned_error_string - something like the following should fix that Do you think that Apache is not reading the HTTP_NOT_FOUND.html.var file correctly which explicitly states that it should be text/html? -- Jerry Baker
Re: [PATCH] Re: Apache 2.0.34-dev Sends Wrong Content-Type on 404
On Thu, 7 Mar 2002, Jerry Baker wrote: Do you think that Apache is not reading the HTTP_NOT_FOUND.html.var file correctly which explicitly states that it should be text/html? is it showing the content from that var file? what is the content you are seeing (the plain html). sterling
Re: [PATCH] Re: Apache 2.0.34-dev Sends Wrong Content-Type on 404
[EMAIL PROTECTED] wrote: On Thu, 7 Mar 2002, Jerry Baker wrote: Do you think that Apache is not reading the HTTP_NOT_FOUND.html.var file correctly which explicitly states that it should be text/html? is it showing the content from that var file? what is the content you are seeing (the plain html). sterling Straight out of the var file (from the en section). -- Jerry Baker
Re: Torching ap_document_root
On Thu, Mar 07, 2002 at 02:25:56PM -0800, Greg Stein wrote:
server/core.c:661
AP_DECLARE(const char *) ap_document_root(request_rec *r)
If we shouldn't use it, why is it still here?
So the /* don't use this! */ comment should go?
I would say rewrite it to be something like:
Modules shouldn't be worried about the document root. If you need to call
this function, then you should ask yourself why. Modules should be more
concerned with r-uri and r-filename.
There are some cases modules need to have access to the document root
(if not modify it for the duration of the request).
In the case of using a CGI with mod_vhost_alias it would be
nice to be able to have the CGI have access to the virtual document root
via ENV{DOCUMENT_ROOT}. Right now this doesn't seem possible because
mod_vhost_alias does not have access to it and otherwise
ap_add_cgi_vars(r) resets it if we set it via r-subprocess_env in
mod_vhost_alias.
We actually had to hack the core to get this to function appropriately.
Cheers,
--
Sander van Zoest +1 (619) 881-3000
Yahoo!, Inc. [EMAIL PROTECTED]
http://www.yahoo.com/ http://sander.vanzoest.com/
Re: [PATCH] Re: Apache 2.0.34-dev Sends Wrong Content-Type on 404
On Thu, 7 Mar 2002, Jerry Baker wrote: [EMAIL PROTECTED] wrote: On Thu, 7 Mar 2002, Jerry Baker wrote: Do you think that Apache is not reading the HTTP_NOT_FOUND.html.var file correctly which explicitly states that it should be text/html? is it showing the content from that var file? what is the content you are seeing (the plain html). sterling Straight out of the var file (from the en section). well, the workaround is to set DefaultType text/html. The real problem, however, seems to be the fact that only the subrequest gets the content type set to text/html in this case, while the main request still has the content_type set to NULL (hence it uses the default). I'll work on a patch that properly sets the content type to the type in the var file. sterling
Re: Compiling apache2 against glibc 2.2.5
On Thu, Mar 07, 2002 at 05:52:15PM -0600, Austin Gonyou wrote: Glibc 2.2.5 was compiled with gcc3. This is supposed to be allowable with glibc 2.2.5, since it was unsupported prior. Does anyone know of any issues doing this? I think you need the latest gcc version (3.0.4?) to compile glibc 2.2.5 properly. But, I'm not sure. I'm not seeing any problems here with 2.2.4, but I don't trust gcc3 to compile glibc for a few more point releases. My binaries are portable, and that doesn't seem to be a problem. I'm trying to gather information as I continue to try to chase down the php4.2-dev + apache2 issue on this target platform. What's your problem again? -- justin
