[STATUS] (flood) Wed Feb 4 23:46:06 EST 2004
flood STATUS: -*-text-*- Last modified at [$Date: 2003/07/01 20:55:12 $] Release: 1.0: Released July 23, 2002 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: * I get a SIGBUS on Darwin with our examples/round-robin-ssl.xml config, on the second URL. I'm using OpenSSL 0.9.6c 21 dec 2001. * 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. * APR needs to have a unified interface for ephemeral port exhaustion, but aparently Solaris and Linux return different errors at the moment. Fix this in APR then take advantage of it in flood. * The examples/analyze-relative scripts fail when there are less than 5 unique URLs. Other features that need writing: * More analysis and graphing scripts are needed * 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. Jacek is working on a Mozilla application, codename Flood URL bag (much like Live HTTP Headers) and small HTTP proxy. * 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. * 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,
Compiling error: flood_net.c:81: error: too many arguments to function `apr_socket_create'
I checkout the cvs and got the lastest flood code, everything goes fine untill the final make all is typed in. The error is flood_net.c:81: warning: passing arg 4 of `apr_socket_create' makes pointer from integer without a cast flood_net.c:81: error: too many arguments to function `apr_socket_create' make: *** [flood_net.lo] Error 1 Then, make exits. Anyone who knows how to solve this drop me a hint, please. Thanks in advance. -- www.viator.com
Re: License 2.0
On Wed, 2004-02-04 at 19:41, André Malo wrote: Anyone already working on switching to it? I'm starting now with the code. Please speak up, if there's already work done. AFAIK, noone is. Go for it. Sander
[PATCH] More sensible behavior(?) when zero-length pid file is found
When, with httpd-2.1, the pid file exists but has a zero size, then
httpd refuses to start.
The attached patch changes this behavior and removes the empty pid file
(but only if it exists AND is empty) and logs a message:
(17)File exists: Zero-length PID file logs/httpd.pid ignored.
to the console during startup.
Not a very frequent error indeed
Martin
--
[EMAIL PROTECTED] | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
? server/core.c.off
? server/export_files.off
? server/mpm/mpmt_pthread/.deps
? server/mpm/mpmt_pthread/.libs
? server/mpm/mpmt_pthread/Makefile
? server/mpm/mpmt_pthread/libmpmt_pthread.la
? server/mpm/mpmt_pthread/mpmt_pthread.lo
? server/mpm/mpmt_pthread/scoreboard.lo
Index: server/log.c
===
RCS file: /home/cvs/httpd-2.0/server/log.c,v
retrieving revision 1.140
diff -u -r1.140 log.c
--- server/log.c12 Jan 2004 22:48:08 - 1.140
+++ server/log.c5 Feb 2004 12:31:32 -
@@ -696,6 +696,7 @@
const char *fname;
char *buf, *endptr;
apr_size_t bytes_read;
+apr_finfo_t finfo;
if (!filename) {
return APR_EGENERAL;
@@ -713,18 +714,31 @@
return rv;
}
+/* If there's a zero length pid file, unlink it */
+if (APR_SUCCESS == apr_file_info_get(finfo, APR_FINFO_SIZE, pid_file)
+0 == finfo.size) {
+apr_file_close(pid_file);
+if (APR_SUCCESS == apr_file_remove(fname, p))
+ap_log_error(APLOG_MARK, APLOG_STARTUP|APLOG_ERR, APR_EEXIST,
+ NULL, Zero-length PID file %s ignored., filename);
+return APR_ENOENT;
+}
+
/* Ensure null-termination, so that strtol doesn't go crazy. */
buf = apr_palloc(p, BUFFER_SIZE);
buf[BUFFER_SIZE - 1] = '\0';
rv = apr_file_read_full(pid_file, buf, BUFFER_SIZE - 1, bytes_read);
if (rv != APR_SUCCESS rv != APR_EOF) {
+apr_file_close(pid_file);
return rv;
}
/* If we fill the buffer, we're probably reading a corrupt pid file.
* To be nice, let's also ensure the first char is a digit. */
if (bytes_read == BUFFER_SIZE - 1 || !apr_isdigit(*buf)) {
+apr_file_close(pid_file);
+
return APR_EGENERAL;
}
Re: FileSystem v.s. Other Resources [was configurable Location?]
Let's do this in 2.1 by splitting out the file system, and if the filesystem module isn't handling a request, it won't be serving content but also won't be invoking the directory walk or stat-ing files. this all sounds kinda interesting, and similar to the way auth has been set up in 2.1 - more directives and modules, but more flexibility and power. Oh last observation - it should become (in 2.1) nearly impossible for folks to just bork around with the contents of r-filename and r-finfo, first by stripping them from the request rec, and second by providing an API to the filesystem module that lets another module link into another file. That API would prevent module authors from bypassing the filesystem module's internal security. this has come up before, and I'd love to see an API that prevents accidental disagreement between r-filename and r-finfo (for one). IIRC, there was supposed to be some discussion at the hackathon about this, but it sounds like I didn't miss it :) --Geoff
Re: Capabilities to provide UDP (not TCP) services with Apache
Yeah, it is a little weird, but not HTTP, another protocol on top of UDP specific to our application. MPM, so that section is the jumping-off point for considering UDP instead of TCP, and the mod_echo for refernce to another protocol (though TCP) being implemented in a module. In fact, the worker thread model was in my follow-up question, since we would want to make sure that our module (if we can write one that does what we want without hitting the central code) would still be able to take advantage of those worker-model schemes. As you can tell I am not as familiar with the deep architecture, just starting the investigation and looking for pointers. Thanks for your response! Matthew Quoting William A. Rowe, Jr. [EMAIL PROTECTED]: I'm totally confused now :) Do you want Apache to handle the UDP request as an HTTP request? Or do you want a UDP port that does something else? First if you want a pool of UDP listeners, explore the MPM - it's the MPM's job to dispatch requests from TCP, so it would make sense to build upon another MPM to handle the connections. Second if you want to handle a protocol other than HTTP, see mod_echo as an example (trivial of course, just as the echo protocol is trivial.) Bill At 06:22 PM 2/4/2004, Matthew Gress wrote: I am curious about what it would take to use an alternate protocol at layer 4 with apache. I have already posted to the users list and was referred here. Apache can communicate with several TCP protocols but I have a module project which needs UDP communications as well. I have searched the documentation, archives, and 2.0.48 HTTPD server source for this and all I find are references for beos, testcockets, LDAP, DNS lookups and some OS-related stuff regarding NIS. Oh yeah, and an old SSL exploit apparently made HTTPD open a UDP listener too... In any case, I have not found a reference to how to configure apache to do this and need to know where I should start to create or adapt for this functionality. We realized that we might have to code this personally to make this work, but would rather not if it is already in existence. Another question I have is, can we create a module that services UDP connections without hitting the cental apache server code. Thanks! Matthew Gress
Re: FileSystem v.s. Other Resources [was configurable Location?]
Thanks for the feedback, Will. William A. Rowe, Jr. wrote: At 03:39 PM 2/4/2004, [EMAIL PROTECTED] wrote: But then if I play devil's advocate, someone could see the new directive and turn it on when it's not appropriate and cause Bad Things to happen. Mainly I'm looking for comments on whether this should be configurable or not. Yes, I'm one who will agree with your devil's position :) I know the problem you are trying to solve, great! and changing the behavior of Directory isn't quite the solution... I'm only changing Location ... Directory is unaffected. Issue 1: Walking the filesystem (the stat aspect of Directory and File) for something that doesn't live there is stupid :) We agree, and this must be fixed in 2.1 cool! Issue 2: Matching directories when something is outside of the filesystem is simply wasteful, and here too we agree. The problem is that you want to add layers of additional directives, which would change the behavior of Directory or Location , only Location , in a way that IMO is consistent with the existing documentation, but not the existing code of course. in ways that would allow the user to seriously compromise what they had explicitly configured for security. This is unwise. Let's look at the two issues above; Effect/Issue 1: Bypassing the filesystem canonicalization would be very bad on certain platforms such as windows, depending on case sensitivity, etc. It would also bypass *user configured* options such as avoiding symlinks. only for Location If the admin is telling us the content is outside the filesystem, I don't think filesystem canonicalization or symlinks are relevant. Effect/Issue 2: Bypassing the directory block walk would ignore the very Directory sections that the user explicitly put in their config. This too is bad. This is only for Location . There is no change to the behavior of Directory . There is only one way that sounds kinda religious...in software there are generally a number of ways to solve a problem :-) to avoid these consequences, and still save ourselves the pain of the filesystem walk and Directory block handling... I'm only changing Location === Break out file handling as a separate component === I've proposed in the past the simple directive FilesystemMount /path/to/files At first glance it looks like a key difference is that you are approaching it by saying that it's OK to have Location map to a real filesystem and providing config to explicitly specify the mapping. I'm advocating going the other way and allowing Location to be treated as if it is really outside of the filesystem. A complication to treating Location as if it's outside the filesystem is the doc that states Location / is a quick way to apply a config to the whole server. It will indeed do that today, unfortunately. I believe another quick way to get the same result is to put your config directives outside of any container. If that's true, I would prefer to see that doc for Location / removed. If the change to the behavior of Location is configurable, this is not an issue. If it's not configurable, then we probably should treat Location / as if it's in the filesystem - a special case for backwards compatibility. I'd like to study your comments more after my coffee kicks in :-) Obviously you've given a lot of thought to this issue so I want to see if I can understand where you're coming from. Greg
Re: [PATCH] configurable Location block speed up
Joshua Slive wrote: (without closer looking at the code) I'd suggest rather Location [virtual] /uri-path /Location where the virtual keyword defines that the location is independent from filesystem. Perhaps I'm misunderstanding the issue, but neither of these make sense to me. It is not really the behavior of the Location block that is changing. Location always acts outside the filesystem. What is changing is that a certain directive inside a Location block should be applied differently. So shouldn't this just be SetVirtualHandler server-status or SetHandler virtual server-status Joshua and André, thanks. Both of you are better at user interfaces than I am. But it sounds like we first need to decide if configuring/assuming Location to be truly outside the filesystem is the way to go. Greg
Re: FileSystem v.s. Other Resources [was configurable Location?]
I just want to add a couple notes here on what I see as user-expectations. The problem is that you want to add layers of additional directives, which would change the behavior of Directory or Location , only Location , in a way that IMO is consistent with the existing documentation, but not the existing code of course. [...] A complication to treating Location as if it's outside the filesystem is the doc that states Location / is a quick way to apply a config to the whole server. It will indeed do that today, unfortunately. I believe another quick way to get the same result is to put your config directives outside of any container. If that's true, I would prefer to see that doc for Location / removed. If the change to the behavior of Location is configurable, this is not an issue. If it's not configurable, then we probably should treat Location / as if it's in the filesystem - a special case for backwards compatibility. I wrote the particular doc you quoted earlier, and I meant it more as a recommendation (for security reasons) than a documentation of how apache works. The true description of how apache is supposed to function is here: http://httpd.apache.org/docs-2.0/sections.html (But it is a little vauge, because my knowledge of the internals of configuration merging was not sufficient to clarify it the last time I went through.) Many people do, in fact, use Location for filesystem-related things. See the examples in the mod_dav docs for one: http://httpd.apache.org/docs-2.0/mod/mod_dav.html Although I don't think this is esthetically correct, it is not particularly dangerous. Using Location to provide *extra* access is okay, because if you circumvent the Location using filesystem tricks, you just lose the access. Using Location to *restrict* access is not safe, because the restrictions may be circumvented. The other important thing to note is that Location is often used for a reason that is particular to apache configuration merging: those sections are evaluated last. That means that Location / Order deny,allow Deny from all Allow from local.net /Location has a very different effect than the same directives placed in Directory / because it will be evaluated after all Directory and Files sections which could potentially override directives. I'm not saying that this is a strictly correct use of Location, but it is very useful and there is no other easy way to accomplish this apply this directive after everything else effect. I do, however, agree that doing a directory-walk on virtual resources is not nice. But my opinion is that virtualness is a property of the resource, and hence should be designated when selecting the resource. That is why I suggested changing SetHandler rather than Location. Joshua.
Re: FileSystem v.s. Other Resources [was configurable Location?]
At 10:22 AM 2/5/2004, [EMAIL PROTECTED] wrote: Thanks for the feedback, Will. William A. Rowe, Jr. wrote: At 03:39 PM 2/4/2004, [EMAIL PROTECTED] wrote: But then if I play devil's advocate, someone could see the new directive and turn it on when it's not appropriate and cause Bad Things to happen. Mainly I'm looking for comments on whether this should be configurable or not. Yes, I'm one who will agree with your devil's position :) I know the problem you are trying to solve, and changing the behavior of Directory isn't quite the solution... I'm only changing Location ... Directory is unaffected. Well, that's not entirely true. The Directory is affected indirectly, because it no longer applies. The behavior currently is: it applies to everything it matches. This would change it to: it applies to everything it matches unless it also matches a Location, in which case it doesn't apply.
Re: FileSystem v.s. Other Resources [was configurable Location?]
I do, however, agree that doing a directory-walk on virtual resources is not nice. But my opinion is that virtualness is a property of the resource, and hence should be designated when selecting the resource. That is why I suggested changing SetHandler rather than Location. And perhaps I'm going way off in left field here, but why should this be user-configurable at all? Shouldn't the (for example) server-status handler know itself that it is a virtual handler, and therefore indicate that the directory-walk should be skipped? Joshua.
RE: mod_ssl not sending Alert upon close ?
Hi, It's been a while since I played with the Apache code, and it'll be nice if somebody can help me here. I put some debug statements in the ssl_engine_io.c - in bio_filter_out_write() and bio_filter_in_read() to see if the alert message is actually being sent, and got the following output: bio_filter_out_write: trying to write inl: 900 (length 0 blen 0) bio_filter_out_write: buffering data (NO WRITE YET) bio_filter_out_flush: trying to flush blen: 900 bio_filter_out_write: trying to write inl: 67 (length 0 blen 0) bio_filter_out_write: buffering data (NO WRITE YET) bio_filter_out_flush: trying to flush blen: 67 (70014)End of file found: bio_filter_in_read: got EOF - returning -1 (at the end) (70014)End of file found: SSL input filter read failed. -- Does the socket fd get closed at this point ? bio_filter_out_write: trying to write inl: 23 (length 0 blen 0) bio_filter_out_write: buffering data (NO WRITE YET) -- This is the close notify message that SSL_set_shutdown() was trying to send - but it never gets sent because the message is buffered. Maybe we need to revisit the logic of bio_filter_out_write() ? Connection to child 0 closed with standard shutdown(server lugia.cup.hp.com:443, client 15.0.70.188) I tried changing the logic in bio_filter_out_write() to send the data as it comes (instead of buffering it,and forcing through flush) - but when we try to send the close notify message, we get the error Bad file number = which means that the socket got closed before SSL_shutdown was issued ? -Madhu -Original Message- From: Mathihalli, Madhusudan Sent: Wednesday, February 04, 2004 6:08 PM To: [EMAIL PROTECTED] Subject: RE: mod_ssl not sending Alert upon close ? -Original Message- From: Geoff Thorpe [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 04, 2004 5:56 PM To: [EMAIL PROTECTED] Cc: Mathihalli, Madhusudan Subject: Re: mod_ssl not sending Alert upon close ? On February 4, 2004 04:39 pm, Mathihalli, Madhusudan wrote: Hi, I was playing with ssldump for the data transferred b/w browser and Apache (2.0.48) - and realized that the Apache2 (+ mod_ssl) does not send the Alert message to the client before closing the connection. Funnily enough, I was just stewing on a similar problem with openssl's builtin s_server application - in that case, the braindamage is in s_server.c's use of SSL_CTX_set_quiet_shutdown(ctx,1). Perhaps apache2 is doing the same thing? I don't think thatz the case - apache2 is NOT doing quiet_shutdown. When I enabled logging of wbio, it appears that it's sending the close notify - but the client doesn't see it. I'm suspecting if we have to flush manually after doing a SSL_set_shutdown(), because there's some special logic in bio_filter_out_write(). -Madhu
Re: apache bug archive?
Jeff, On Mon, 26 Jan 2004 Jeff Trawick wrote : bug was that there were two places where we tried to close a single file descriptor... 2nd close would fail with EBADF unless some other thread had that file descriptor assigned to another file because it got a socket or file or pipe or whatever after the first close() but before the second close()... that could cause the 2nd thread to fail to write data (getting EBADF) or even worse write to some other thread's socket/pipe/file/whatever if thread 3 got that fd assigned in the mean time Thanks for your detailed explanation. I really appreciate it. Since then I try to repeat this bug on a real server with 12 CPUs. I wrote a driver program that repeatedly fetch a cgi URL with each time with unique parameters. The server is configured with worker MPM and cgid module. The driver matches the cgi (in fact, test-cgi in cgi-bin directory) output with the unique parameter sent and raise error if they don't match. However, I couldn't repeat the bug with such setup. I didn't see any mismatch of cgi output from the driver neither do I saw any error message of bad file descriptor being closed in the error log. I wonder what's wrong with my setup? Maybe the test-cgi isn't running long enough? In fact, I try to understand the cgid source code to understand this file descriptor mishandling. However, I couldn't find any place where this file descriptor, which I assume is tempsock in cgid_handler(), is passed to another thread. The closest place I found was the place where tempsock is placed into a bucket b, and then added to the tail of a brigade bb, then ap_pass_brigade (r-output_filters, bb) is called to pass tempsock to next filter. However, it seems ap_pass_brigade() still executes the filter function within the same thread. In other words, tempsock never escaped this thread. How could a second thread get this file descriptor? Thanks a lot again. -Min
[PATCH] mod_cache: returning 304s running the quick handler
This patch make it possible toreturn 304s when using the quick handler,
ifa fresh cache entity is found.
The r-mtime field is usually set in default_handler() (core.c) by calling
ap_update_mtime(), which does not happen when the quick handler
find a fresh cache entry.
Fromcache_url_handler(), the r-mtime field is then used in ap_meets_conditions()
todetermine if the browser/proxy cached copy is older than the one on the current server.
If not, the server should returns a 304.
In our case because the r-mtime field is never set, then the tested variable in
ap_meets_condition() is always set using a call to apr_time_now().
304s are then not possible when using caching modules.
The patchjust update mtime based on what was stored in the lastmod field when the entity was
cachedduring a previous request.
--
+++ modules/experimental/mod_cache.c30 Jan 2004 17:07:15 -@@ -216,6 +216,12 @@ if (lookup) { return OK; }++ info = (cache-handle-cache_obj-info);+ if (info info-lastmod) {+ ap_update_mtime(r, info-lastmod);+ }+ rv = ap_meets_conditions(r);--
There is probably a PR, but I did not find it; any idea if there is one?Please let me know if you think there is a problem/better way, if not I will commit
the attached patch first partof next week.
Thanks,
Jean-Jacques
mod_cache.304.patch
Description: Binary data
Re: FileSystem v.s. Other Resources [was configurable Location?]
At 10:43 AM 2/5/2004, Greg Marr wrote: At 10:22 AM 2/5/2004, [EMAIL PROTECTED] wrote: Thanks for the feedback, Will. William A. Rowe, Jr. wrote: At 03:39 PM 2/4/2004, [EMAIL PROTECTED] wrote: But then if I play devil's advocate, someone could see the new directive and turn it on when it's not appropriate and cause Bad Things to happen. Mainly I'm looking for comments on whether this should be configurable or not. Yes, I'm one who will agree with your devil's position :) I know the problem you are trying to solve, and changing the behavior of Directory isn't quite the solution... I'm only changing Location ... Directory is unaffected. Well, that's not entirely true. The Directory is affected indirectly, because it no longer applies. The behavior currently is: it applies to everything it matches. This would change it to: it applies to everything it matches unless it also matches a Location, in which case it doesn't apply. Right - I understand. I'm saying (as you pointed out) that it's too dangerous :) Defies the principle of least surprise. They configure Dir blocks only to have them ignored. The only safe way to do what you are suggesting, is to yank the default file handler from under the request anytime the user has overridden the Dir checks. Simplest way to do that is bind them together as a filesystem module. Oh, the same problems (of yanking Dir out from under the user) would be true of the CGI handler, as well as third party modules that do things with the filesystem. It would be important that they could explicitly enable the module to add Dir handling. Which brings us back to square one. I'd actually argued a long time ago that a module that handles requests outside of the filesystem should be responsible for bypassing the Dir handler itself. For example, mod_proxy satisfies the map_to_storage hook on it's own, therefore never hitting Dir . Bill
Re: FileSystem v.s. Other Resources [was configurable Location?]
At 09:22 AM 2/5/2004, [EMAIL PROTECTED] wrote: Effect/Issue 1: Bypassing the filesystem canonicalization would be very bad on certain platforms such as windows, depending on case sensitivity, etc. It would also bypass *user configured* options such as avoiding symlinks. only for Location If the admin is telling us the content is outside the filesystem, I don't think filesystem canonicalization or symlinks are relevant. But the question is how the admin communicates that to us. You are suggesting we allow Location virtual /not/a/file to say it's outside of the file system. *However* are you preventing a file from being served? Guess that is the gist of my concern. Effect/Issue 2: Bypassing the directory block walk would ignore the very Directory sections that the user explicitly put in their config. This too is bad. This is only for Location . There is no change to the behavior of Directory . to avoid these consequences, and still save ourselves the pain of the filesystem walk and Directory block handling... I'm only changing Location Wait - so you say. But the effect is to disable Directory block handling, am I confused on this point??? If you ignore valid Directory blocks because somewhere else the admin says Wait - this location is virtual! then are you also preventing those files from being served? If not this is what I suggest is a violation of the principal of least surprise. === Break out file handling as a separate component === I've proposed in the past the simple directive FilesystemMount /path/to/files At first glance it looks like a key difference is that you are approaching it by saying that it's OK to have Location map to a real filesystem and providing config to explicitly specify the mapping. I'm advocating going the other way and allowing Location to be treated as if it is really outside of the filesystem. Here's what I'm suggesting; 1. Everything in Apache is at some location. Location is a predictable factor because every URI becomes a location. A Location block will always override all other configurations, location blocks are always applied as least-to-most significant if they are absolute, and then pattern matching location blocks are applied after that. 2. Some things in Apache are in the Filesystem, some are in JK, some are in an application (a cgi with PATH_INFO). These aren't always 1:1 to the filesystem, except in the case of filesystem-based modules such as our default handler and the current cgi modules. 3. If something is in the Filesystem, then Directory and Files should be applied. If something is not in the filesystem, than no, it should not, and that other backend (e.g. proxy) should have it's own container blocks to deal with the resource (e.g. Proxy blocks.) Overloading can become a very confusing a dangerous game for admins to properly configure their servers. 4. If something is not in the Filesystem, there should be no way that our own CGI handler or default file handler should be allowed to handle the request. If Apache 5. Whatever resource (Filesystem or what have you) that claims to own the resource for config block processing should be the only available handler to deal with the resource on the back end. Jumping from one resource context in the configuration phase to another resource resource in the handler phase is very dangerous. Beyond what I've detailed above, I'm flexible about how it works/what the various directives are, etc. Bill
Re: mod_ssl not sending Alert upon close ?
I've seen some unclean shutdown errors a few times but never managed to get a repro case. What client are you using, how do you reproduce this? I presume you have the same SetEnvIf ssl-unclean-shutdown settings for broken clients when comparing 1.3 and 2.0 behaviour? On Thu, Feb 05, 2004 at 11:06:57AM -0800, Mathihalli, Madhusudan wrote: Hi, It's been a while since I played with the Apache code, and it'll be nice if somebody can help me here. I put some debug statements in the ssl_engine_io.c - in bio_filter_out_write() and bio_filter_in_read() to see if the alert message is actually being sent, and got the following output: bio_filter_out_write: trying to write inl: 900 (length 0 blen 0) bio_filter_out_write: buffering data (NO WRITE YET) bio_filter_out_flush: trying to flush blen: 900 bio_filter_out_write: trying to write inl: 67 (length 0 blen 0) bio_filter_out_write: buffering data (NO WRITE YET) bio_filter_out_flush: trying to flush blen: 67 (70014)End of file found: bio_filter_in_read: got EOF - returning -1 (at the end) (70014)End of file found: SSL input filter read failed. -- Does the socket fd get closed at this point ? bio_filter_out_write: trying to write inl: 23 (length 0 blen 0) bio_filter_out_write: buffering data (NO WRITE YET) -- This is the close notify message that SSL_set_shutdown() was trying to send - but it never gets sent because the message is buffered. Maybe we need to revisit the logic of bio_filter_out_write() ? And you're sure that the client sent a close notify alert before the EOF? joe
RE: mod_ssl not sending Alert upon close ?
I tried using all the three 'unclean', 'standard' and 'accurate' shutdown methods. I'm
using MSIE 6.0 (and can attach the ssldump comparision for both Apache 1.3 and 2.x if
required)
As regards reproducing, I think you can reproduce it in any standard installation.
Here's a partial 'tusc' output. As you can see, the socket has been closed much before
the Alert message was *tried* to be sent !
-Madhu
1076016143.543190 {621927} write(10, 0x7af0fcc8, 81) . = 81
[ T h u F e b 0 5 1 3 : 2 2 : 2 3 2 0 0 4 ] [ i n f o
] b i o _ f i l t e r _ o u t _ f l u s h : t r y i n g t
o f l u s h b l e n : 6 7 \n
1076016143.543457 {621927} writev(13, 0x7af0fc88, 1) . = 67
1403\0\001011603\0\08 86e5adcaP q 5 b2bdd810ffc11adc- e aaa613cc
\0H 9fe6d61 l D ! # cas M w W 80x b4\r` t cdce\n6 cd, P L f5x 4
d0O e
1076016143.543774 {621927} fcntl(12, F_SETLKW, 0x7b019574) = 0
1076016143.543943 {621927} time(NULL) = 1076016143
1076016143.544052 {621927} fcntl(12, F_SETLKW, 0x7b019584) = 0
1076016143.920487 {621927} poll(0x7af0fe50, 1, 30) ... = 1
1076016143.920587 {621927} read(13, 0x402b6810, 8000) = 0
1076016143.920685 {621927} gettimeofday(0x7af0f448, NULL) = 0
1076016143.920813 {621927} shutdown(13, SHUT_WR) . = 0
1076016143.920898 {621927} poll(0x7af0f650, 1, 2000) . = 1
1076016143.920984 {621927} read(13, 0x7af0f208, 512) . = 0
1076016143.924105 {621927} close(13) . = 0
1076016143.924239 {621927} gettimeofday(0x7af11788, NULL) = 0
1076016143.932207 {621927} write(10, 0x7af0f708, 98) . = 98
[ T h u F e b 0 5 1 3 : 2 2 : 2 3 2 0 0 4 ] [ i n f o
] b i o _ f i l t e r _ o u t _ w r i t e : t r y i n g t
o w r i t e i n l : 2 3 ( l e n g t h 0 b l e n 0
) \n
1076016143.932510 {621927} gettimeofday(0x7af11788, NULL) = 0
1076016143.932608 {621927} write(10, 0x7af0f708, 86) . = 86
[ T h u F e b 0 5 1 3 : 2 2 : 2 3 2 0 0 4 ] [ i n f o
] b i o _ f i l t e r _ o u t _ w r i t e : b u f f e r i n
g d a t a ( N O W R I T E Y E T ) \n
1076016143.932844 {621927} gettimeofday(0x7af11448, NULL) = 0
1076016143.932934 {621927} write(10, 0x7af0f3c8, 135) = 135
[ T h u F e b 0 5 1 3 : 2 2 : 2 3 2 0 0 4 ] [ i n f o
] C o n n e c t i o n t o c h i l d 1 c l o s e d w
i t h s t a n d a r d s h u t d o w n ( s e r v e r l u g
i a . c u p . h p . c o m : 4 4 3 , c l i e n t 1 5 . 0 . 7
0 . 1 8 8 ) \n
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 05, 2004 12:10 PM
To: [EMAIL PROTECTED]
Subject: Re: mod_ssl not sending Alert upon close ?
I've seen some unclean shutdown errors a few times but never managed to
get a repro case. What client are you using, how do you
reproduce this?
I presume you have the same SetEnvIf ssl-unclean-shutdown settings for
broken clients when comparing 1.3 and 2.0 behaviour?
On Thu, Feb 05, 2004 at 11:06:57AM -0800, Mathihalli, Madhusudan wrote:
Hi,
It's been a while since I played with the Apache code,
and it'll
be nice if somebody can help me here.
I put some debug statements in the ssl_engine_io.c - in
bio_filter_out_write() and bio_filter_in_read() to see if the alert
message is actually being sent, and got the following output:
bio_filter_out_write: trying to write inl: 900 (length 0 blen 0)
bio_filter_out_write: buffering data (NO WRITE YET)
bio_filter_out_flush: trying to flush blen: 900
bio_filter_out_write: trying to write inl: 67 (length 0 blen 0)
bio_filter_out_write: buffering data (NO WRITE YET)
bio_filter_out_flush: trying to flush blen: 67
(70014)End of file found: bio_filter_in_read: got EOF -
returning -1 (at the end)
(70014)End of file found: SSL input filter read failed.
-- Does the socket fd get closed at this point ?
bio_filter_out_write: trying to write inl: 23 (length 0 blen 0)
bio_filter_out_write: buffering data (NO WRITE YET)
-- This is the close notify message that
SSL_set_shutdown() was trying to send - but it never gets sent
because the message is buffered. Maybe we need to revisit the
logic of bio_filter_out_write() ?
And you're sure that the client sent a close notify alert before the
EOF?
joe
RE: mod_ssl not sending Alert upon close ?
Okay. here's what I think is happening : (Client = C Server - S)
C - S : initiates connection
C - S : handshake
S - C : server sends application data
S - C : server tries to read from the socket
- finds nothing (0 bytes returned)
- assumes transaction is completed, and starts cleanup process
- closes the connection first
- frees the pool, which invokes ssl_io_filter_cleanup() and inturn
ssl_io_filter_shutdown()
- ssl_io_filter_shutdown() tries to send 'Close notify'
OOPS ! The connection has already been terminated
Any comments ?
-Madhu
-Original Message-
From: Mathihalli, Madhusudan
Sent: Thursday, February 05, 2004 1:31 PM
To: [EMAIL PROTECTED]
Subject: RE: mod_ssl not sending Alert upon close ?
I tried using all the three 'unclean', 'standard' and
'accurate' shutdown methods. I'm using MSIE 6.0 (and can
attach the ssldump comparision for both Apache 1.3 and 2.x if required)
As regards reproducing, I think you can reproduce it in any
standard installation. Here's a partial 'tusc' output. As you
can see, the socket has been closed much before the Alert
message was *tried* to be sent !
-Madhu
1076016143.543190 {621927} write(10, 0x7af0fcc8, 81) . = 81
[ T h u F e b 0 5 1 3 : 2 2 : 2 3 2 0 0 4 ] [ i n f o
] b i o _ f i l t e r _ o u t _ f l u s h : t r y i n g t
o f l u s h b l e n : 6 7 \n
1076016143.543457 {621927} writev(13, 0x7af0fc88, 1) . = 67
1403\0\001011603\0\08 86e5adcaP q 5 b2bdd810ffc11adc- e aaa613cc
\0H 9fe6d61 l D ! # cas M w W 80x b4\r` t cdce\n6 cd, P L f5x 4
d0O e
1076016143.543774 {621927} fcntl(12, F_SETLKW, 0x7b019574) = 0
1076016143.543943 {621927} time(NULL) = 1076016143
1076016143.544052 {621927} fcntl(12, F_SETLKW, 0x7b019584) = 0
1076016143.920487 {621927} poll(0x7af0fe50, 1, 30) ... = 1
1076016143.920587 {621927} read(13, 0x402b6810, 8000) = 0
1076016143.920685 {621927} gettimeofday(0x7af0f448, NULL) = 0
1076016143.920813 {621927} shutdown(13, SHUT_WR) . = 0
1076016143.920898 {621927} poll(0x7af0f650, 1, 2000) . = 1
1076016143.920984 {621927} read(13, 0x7af0f208, 512) . = 0
1076016143.924105 {621927} close(13) . = 0
1076016143.924239 {621927} gettimeofday(0x7af11788, NULL) = 0
1076016143.932207 {621927} write(10, 0x7af0f708, 98) . = 98
[ T h u F e b 0 5 1 3 : 2 2 : 2 3 2 0 0 4 ] [ i n f o
] b i o _ f i l t e r _ o u t _ w r i t e : t r y i n g t
o w r i t e i n l : 2 3 ( l e n g t h 0 b l e n 0
) \n
1076016143.932510 {621927} gettimeofday(0x7af11788, NULL) = 0
1076016143.932608 {621927} write(10, 0x7af0f708, 86) . = 86
[ T h u F e b 0 5 1 3 : 2 2 : 2 3 2 0 0 4 ] [ i n f o
] b i o _ f i l t e r _ o u t _ w r i t e : b u f f e r i n
g d a t a ( N O W R I T E Y E T ) \n
1076016143.932844 {621927} gettimeofday(0x7af11448, NULL) = 0
1076016143.932934 {621927} write(10, 0x7af0f3c8, 135) = 135
[ T h u F e b 0 5 1 3 : 2 2 : 2 3 2 0 0 4 ] [ i n f o
] C o n n e c t i o n t o c h i l d 1 c l o s e d w
i t h s t a n d a r d s h u t d o w n ( s e r v e r l u g
i a . c u p . h p . c o m : 4 4 3 , c l i e n t 1 5 . 0 . 7
0 . 1 8 8 ) \n
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 05, 2004 12:10 PM
To: [EMAIL PROTECTED]
Subject: Re: mod_ssl not sending Alert upon close ?
I've seen some unclean shutdown errors a few times but never
managed to
get a repro case. What client are you using, how do you
reproduce this?
I presume you have the same SetEnvIf ssl-unclean-shutdown settings for
broken clients when comparing 1.3 and 2.0 behaviour?
On Thu, Feb 05, 2004 at 11:06:57AM -0800, Mathihalli,
Madhusudan wrote:
Hi,
It's been a while since I played with the Apache code,
and it'll
be nice if somebody can help me here.
I put some debug statements in the ssl_engine_io.c - in
bio_filter_out_write() and bio_filter_in_read() to see if the alert
message is actually being sent, and got the following output:
bio_filter_out_write: trying to write inl: 900 (length 0 blen 0)
bio_filter_out_write: buffering data (NO WRITE YET)
bio_filter_out_flush: trying to flush blen: 900
bio_filter_out_write: trying to write inl: 67 (length 0 blen 0)
bio_filter_out_write: buffering data (NO WRITE YET)
bio_filter_out_flush: trying to flush blen: 67
(70014)End of file found: bio_filter_in_read: got EOF -
returning -1 (at the end)
(70014)End of file found: SSL input filter read failed.
-- Does the socket fd get closed at this point ?
bio_filter_out_write: trying to write inl: 23 (length 0 blen 0)
bio_filter_out_write: buffering data (NO WRITE YET)
-- This is the close notify message that
SSL_set_shutdown() was trying to send - but it never gets sent
because the message
PACKAGE_* #defines
I bumped into a little strange side effect of autoconf with Apache 2.0.48. The header file httpd.h includes ap_config.h, which in turn includes ap_config_auto.h (on Unix/Linux). Now, this header, ap_config_auto.h has the definitions of PACKAGE_NAME, PACKAGE_VERSION etc., presumably generated by autoconf. The are all set to empty strings. If one is developing an application (e.g. module) using autoconf and wants to use those same #defines, the compiler will start spewing ugly warnings about all those being previously defined, which may confuse people that are trying to compile this application. Is there any real need to actually have those in ap_config_auto.h? I'm pretty sure they would not be what any application writer would want to have in his own code... -- Bojan
