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