Re: [PROPOSAL] Move AUTH_LDAP to /experimental (was: authentication rewrite)
I'd like to second that ! Peter. Brad Nicholes wrote: > >Now that 2.0.40 has been released and we are in development of .41 > and the fact that there has been a proposal for re-architecting the AUTH > modules, I would like to propose that we move AUTH_LDAP out of it's own > project and into experimental. This will enable AUTH_LDAP to get more > exposure as an external module, allow it to be included in future > releases of Apache 2 for testing and stabilization, and make sure that > it is not overlooked in future development. LDAP is an important > authentication method and should be supported in Apache. > > Brad > > Brad Nicholes > Senior Software Engineer > Novell, Inc., the leading provider of Net business solutions > http://www.novell.com > > >>> [EMAIL PROTECTED] Tuesday, August 27, 2002 8:53:19 AM >>> > Hi - > > Shouldn't a new thread be spawned for an(other) ldap vote (its deja vu > all > over again :) > > sterling > > >-- Original Message -- > >Reply-To: [EMAIL PROTECTED] > >Date: Tue, 27 Aug 2002 08:20:05 -0600 > >From: "Brad Nicholes" <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> > >Subject: Re: authentication rewrite > > > > > >+1 > > > >Brad Nicholes > >Senior Software Engineer > >Novell, Inc., the leading provider of Net business solutions > >http://www.novell.com > > > [EMAIL PROTECTED] Tuesday, August 27, 2002 4:20:43 AM >>> > >Justin Erenkrantz wrote: > > > >> Ideally, you could use the LDAP filters that most PAM > >implementations > >> use, but definitely allow the user to tweak them. I'd like to get > >> mod_auth_ldap ported to this, and if we move towards a > >provider-based > >> system, I think mod_auth_ldap should be moved back into the core. > >> (Namely because that's the preferred auth for DAV ACL support as it > >> is hierarchical.) > > > >I want to see auth_ldap moved into experimental so that it is > included > > > >in any work done on overhauling the auth stuff. > > > >Currently the code is receiving minimal exposure where it is. > > > >Regards, > >Graham > >-- > >- > >[EMAIL PROTECTED] > > "There's a moon > > over Bourbon Street > > tonight..." > >
segfault when r->filename is NULL
In apache-1.3 it was possible to shortcut the translation handler, by
returning OK right away, thus saving several stat() syscalls when you
knew that your handler is virtual and doesn't need to run the
uri->filename translation.
In httpd-2.0 this doesn't work anymore. mod_mime's find_ct() segfaults
at:
if ((fn = strrchr(r->filename, '/')) == NULL) {
fn = r->filename;
}
because shortcutting the trans handler leaves r->filename equal to NULL.
(gdb) where
#0 0x402f30e3 in ?? () from /lib/i686/libc.so.6
#1 0x080d1d8b in ap_run_type_checker (r=0x8684f98) at request.c:116
#2 0x080d2353 in ap_process_request_internal (r=0x0) at request.c:271
#3 0x08097509 in ap_process_request (r=0x86106ec) at http_request.c:286
#4 0x08093489 in ap_process_http_connection (c=0x867f088) at
http_core.c:293
#5 0x080c76ab in ap_run_process_connection (c=0x867f088) at connection.c:85
#6 0x080bcaf4 in child_main (child_num_arg=0) at prefork.c:696
#7 0x080bcc9d in make_child (s=0x815d2e0, slot=0) at prefork.c:736
#8 0x080bccfe in startup_children (number_to_start=4) at prefork.c:808
#9 0x080bd43b in ap_mpm_run (_pconf=0x81109f0, plog=0x8156b08,
s=0x810e9e8) at prefork.c:1024
#10 0x080c235d in main (argc=4, argv=0xb604) at main.c:645
#11 0x40296082 in ?? () from /lib/i686/libc.so.6
I've traced the difference to ap_directory_walk, where in 1.3 version
it did:
if (r->filename == NULL) {
r->filename = ap_pstrdup(r->pool, r->uri);
r->finfo.st_mode = 0; /* Not really a file... */
r->per_dir_config = per_dir_defaults;
return OK;
}
whereas in 2.0 it does:
if (r->filename == NULL) {
ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
"Module bug? Request filename is missing for URI
%s",
r->uri);
return OK;
}
hence the segfault.
I understand that the shortcutting trick worked in 1.3 only because
the default core_map_to_storage() was executed, which was fixing-up
the r->filename.
So I've two questions:
1) when the default trans handler fails to locate the file on the
filesystem, it assigns the
r->uri to it. but this is not a filename. why not init filename to
"", when the r object is created and then one doesn't need to find
workarounds to set r->filename to a non-existing path.
2) shouldn't Apache cleanly assert if after the translation
phase r->filename is still NULL? segfaulting doesn't help the
module authors to trace the problem. Especially as you can see from
the trace I've attached the trace is not very useful, and I had to
step through with debugger to find the offending code.
I'm not sure what's the best place for this check, but probably
right after:
if ((access_status = ap_run_translate_name(r))) {
return decl_die(access_status, "translate", r);
}
is the obvious place.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: authentication rewrite
On Tue, Aug 27, 2002 at 05:02:19PM -0700, Justin Erenkrantz wrote: > On Tue, Aug 27, 2002 at 05:03:11PM -0700, Greg Stein wrote: > > Put it in there, then :-) > > > > I haven't really seen any objects so far. And hey... this *is* version > > control. It can always be backed out :-) > > I don't want to add it in and then have to back it out because people > didn't realize that it is going to hose existing configs. > > If we're cool with that, then fine. -- justin Oh yah... the config thing. There isn't a way to keep existing configs? To simply deprecate older configurations? Is the problem that older configs need to add a new directive? And if so, then could we add it automagically? Yes, this would hard-code a dependency between two modules, but that would be better than a broken config. And we can take out the auto-config at some future point. It would seem that changes to the directives would be easy, and we could also deprecate older directives. In all cases, we'd change our .conf files and the doc, issue warnings for old usage, and then just "wait a while" before removing old support. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: authentication rewrite
On Tue, Aug 27, 2002 at 05:03:11PM -0700, Greg Stein wrote: > Put it in there, then :-) > > I haven't really seen any objects so far. And hey... this *is* version > control. It can always be backed out :-) I don't want to add it in and then have to back it out because people didn't realize that it is going to hose existing configs. If we're cool with that, then fine. -- justin
Re: authentication rewrite
On Tue, Aug 27, 2002 at 03:27:10PM -0700, Justin Erenkrantz wrote: > On Tue, Aug 27, 2002 at 02:43:24PM -0400, [EMAIL PROTECTED] wrote: > > I could send a patch to your current code if that would be clearer - its > > really pretty simple, but would allow the backends to get at least a little > > more powerful (and would solve the ldap_prop case i illustrated above > > Definitely. =) > > I want to get this into the repository, so we can start fixing it. > I don't want it to be developed outside of the tree. -- justin Put it in there, then :-) I haven't really seen any objects so far. And hey... this *is* version control. It can always be backed out :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: authentication rewrite
On Tue, Aug 27, 2002 at 02:43:24PM -0400, [EMAIL PROTECTED] wrote: > I could send a patch to your current code if that would be clearer - its > really pretty simple, but would allow the backends to get at least a little > more powerful (and would solve the ldap_prop case i illustrated above Definitely. =) I want to get this into the repository, so we can start fixing it. I don't want it to be developed outside of the tree. -- justin
Apache httpd-ldap module vs. AIX
Has anyone gotten the Apache 2 httpd-ldap sub-project modules to *work* (not just build) on AIX? I tried with Apache 2.0.40 and the mod_ldap.so still won't load and it won't tell me why not [Overall, Apache 2 is a bear on AIX -- given gcc symbol shuffling exercises and libtool issues.] -- Jess Holle
Re: more on the charter (was: El-Kabong -- HTML Parser)
Greg Stein wrote: > > > > Regarding specifically e-k, as a html parser, it's > > got more a family tie, IMO, to the HTTP server project, than APR. > > I think it fits in better among libapreq than in the APR world, > > mostly because it's focused towards the web server and web server > > functionality. > > Eh? I see this as mostly a client library. I'm thinking screen scraping, or > the core of an HTML renderer, or something similar. Yes, it *also* has some > neat server capabilities (filter-based processing). > I was thinking mostly along the lines that under the "web server project" there exists the HTTP specific entities, and a HTML parser would fall into there. But yeah, it could also fit in APR too. But it's not going to ruffle my feathers either way. :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: Apache 1.3.x and 2.0.x Performance Issue
I can check into this (as I said another engineer ran the tests), but these servers were on the same network segments. Also, our customers are seeing roughly the same numbers (at least for Apache 1.3 -- they're not up to 2.0 yet). -- Jess Holle Clay Webster wrote: >Jess, > >Were IIS and Tomcat on the same windows hardware as >the Apache httpds? Are you seeing network issues >(e.g.- rexmits) -- you might have them everywhere, but >your Solaris may not be configured well (ndd,MTU,etc). > >--cw > >-Original Message- >From: Jess M. Holle [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, August 27, 2002 4:30 PM >To: [EMAIL PROTECTED] >Subject: Re: Apache 1.3.x and 2.0.x Performance Issue > > >Ian Holsman wrote: > >Jess M. Holle wrote: > >Both Apache 1.3.x and 2.0.x suffer a severe perfomance issue when the server is on >Windows and the client is Solaris (and perhaps others). > >Before you stop reading this as simply "we know Windows does not perform well", I >should point out that this does not occur when the client is Windows or Linux, nor >when the server is on the same Windows box but is IIS or Tomcat (standalone)! > >Some rough download speeds: > >* recent Apache 1.3.x on Windows: > o client on Solaris (8): 80K/sec > o client on Linux or Windows: 8MB/sec >* recent Apache 2.0.x on Windows: > o client on Solaris (8): 120K/sec > o client on Linux or Windows: 8MB/sec >* IIS on Windows > o any client tried: 8-9 MB/sec >* Tomcat (standalone) on Windows > o any client tried: ~8MB/sec > > >just out of interest does the same thing happen when we have a solaris server and a >windows client? >I'm not sure. I've not yet tried that (and actually another engineer ran all these >tests). I also just noticed that I got some numbers slightly wrong: > >Apache 2.0.39 on Windows > >client on Solaris (8): 649 K/s >client on Linux: 9.1 MB/s > >[I've appended this amended info to the bug report.] > >-- >Jess Holle > > >
RE: Apache 1.3.x and 2.0.x Performance Issue
Jess, Were IIS and Tomcat on the same windows hardware as the Apache httpds? Are you seeing network issues (e.g.- rexmits) -- you might have them everywhere, but your Solaris may not be configured well (ndd,MTU,etc). --cw -Original Message- From: Jess M. Holle [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 27, 2002 4:30 PM To: [EMAIL PROTECTED] Subject: Re: Apache 1.3.x and 2.0.x Performance Issue Ian Holsman wrote: Jess M. Holle wrote: Both Apache 1.3.x and 2.0.x suffer a severe perfomance issue when the server is on Windows and the client is Solaris (and perhaps others). Before you stop reading this as simply "we know Windows does not perform well", I should point out that this does not occur when the client is Windows or Linux, nor when the server is on the same Windows box but is IIS or Tomcat (standalone)! Some rough download speeds: * recent Apache 1.3.x on Windows: o client on Solaris (8): 80K/sec o client on Linux or Windows: 8MB/sec * recent Apache 2.0.x on Windows: o client on Solaris (8): 120K/sec o client on Linux or Windows: 8MB/sec * IIS on Windows o any client tried: 8-9 MB/sec * Tomcat (standalone) on Windows o any client tried: ~8MB/sec just out of interest does the same thing happen when we have a solaris server and a windows client? I'm not sure. I've not yet tried that (and actually another engineer ran all these tests). I also just noticed that I got some numbers slightly wrong: Apache 2.0.39 on Windows client on Solaris (8): 649 K/s client on Linux: 9.1 MB/s [I've appended this amended info to the bug report.] -- Jess Holle
Re: Apache 1.3.x and 2.0.x Performance Issue
Ian Holsman wrote: Jess M. Holle wrote: Both Apache 1.3.x and 2.0.x suffer a severe perfomance issue when the server is on Windows and the client is Solaris (and perhaps others). Before you stop reading this as simply "we know Windows does not perform well", I should point out that this does not occur when the client is Windows or Linux, nor when the server is on the same Windows box but is IIS or Tomcat (standalone)! Some rough download speeds: * recent Apache 1.3.x on Windows: o client on Solaris (8): 80K/sec o client on Linux or Windows: 8MB/sec * recent Apache 2.0.x on Windows: o client on Solaris (8): 120K/sec o client on Linux or Windows: 8MB/sec * IIS on Windows o any client tried: 8-9 MB/sec * Tomcat (standalone) on Windows o any client tried: ~8MB/sec just out of interest does the same thing happen when we have a solaris server and a windows client? I'm not sure. I've not yet tried that (and actually another engineer ran all these tests). I also just noticed that I got some numbers slightly wrong: Apache 2.0.39 on Windows client on Solaris (8): 649 K/s client on Linux: 9.1 MB/s [I've appended this amended info to the bug report.] -- Jess Holle
Re: more on the charter (was: El-Kabong -- HTML Parser)
On Tue, Aug 27, 2002 at 04:14:20PM -0400, Jim Jagielski wrote: > At 12:43 PM -0700 8/27/02, Greg Stein wrote: > > > >> > APR is whatever we want it to be. If we start building things on > > > >You bet! > > Well, it depends on how far you want to take the statement "whatever > we want it to be" :) *duck* Good thing you ducked, or you'd be sportin' a black eye, mister! :-) >... > But it isn't, and shouldn't be, a drop-box for every library or suite > of routines that comes down the path (not that anyone is saying that > it is or will be). Agreed. I think that we're all very wary of that, so we've got a nice little resistance to ending up that way. Two more years from now? *shrug* > Regarding specifically e-k, as a html parser, it's > got more a family tie, IMO, to the HTTP server project, than APR. > I think it fits in better among libapreq than in the APR world, > mostly because it's focused towards the web server and web server > functionality. Eh? I see this as mostly a client library. I'm thinking screen scraping, or the core of an HTML renderer, or something similar. Yes, it *also* has some neat server capabilities (filter-based processing). Because it falls into *both* camps, I don't see it associated with the "HTTP Server Project". > Would it destroy APR to fold e-k into it... I don't think so. Is there > a better place under the ASF than in APR? Maybe :) I obviously don't see it falling into httpd :-). Elsewhere? Not with our current structure. If we created a "web" project, then it could go there. Of course, just about *everything* the ASF does is somehow related to the web, so I'd be wary of ever giving a +1 to creating a "web" project :-) Now, if there was a "document" project, or DOM project, or something like that. We could put the XML parsers, this HTML parser, and prolly some other xml/jakarta tools in there. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: more on the charter (was: El-Kabong -- HTML Parser)
Hi - >-- Original Message -- >Reply-To: [EMAIL PROTECTED] >Date: Tue, 27 Aug 2002 16:14:20 -0400 >To: [EMAIL PROTECTED] >From: Jim Jagielski <[EMAIL PROTECTED]> >Subject: Re: more on the charter (was: El-Kabong -- HTML Parser) >Cc: [EMAIL PROTECTED] > >Would it destroy APR to fold e-k into it... I don't think so. Is there >a better place under the ASF than in APR? Maybe :) I say make it a peer of the apr xml utilities. sterling
Re: Apache 1.3.x and 2.0.x Performance Issue
Jess M. Holle wrote: > Both Apache 1.3.x and 2.0.x suffer a severe perfomance issue when the > server is on Windows and the client is Solaris (and perhaps others). > > Before you stop reading this as simply "we know Windows does not perform > well", I should point out that this does not occur when the client is > Windows or Linux, nor when the server is on the same Windows box but is > IIS or Tomcat (standalone)! > > Some rough download speeds: > > * recent Apache 1.3.x on Windows: > o client on Solaris (8): 80K/sec > o client on Linux or Windows: 8MB/sec > * recent Apache 2.0.x on Windows: > o client on Solaris (8): 120K/sec > o client on Linux or Windows: 8MB/sec > * IIS on Windows > o any client tried: 8-9 MB/sec > * Tomcat (standalone) on Windows > o any client tried: ~8MB/sec > just out of interest does the same thing happen when we have a solaris server and a windows client? > Oddly Apache performance was around 1MB/sec when the request was routed > through it to mod_jk to Tomcat -- which is far worse than the 8MB/sec, > but far better than 80-120K/sec. > > I have filed bugs (12097 and 12099) against Apache 1.3 and 2.0 on these > issues as it is fairly clear that Apache is doing something wrong that > both IIS and Tomcat manage not to do. > > -- > Jess Holle >
Apache 1.3.x and 2.0.x Performance Issue
Both Apache 1.3.x and 2.0.x suffer a severe perfomance issue when the server is on Windows and the client is Solaris (and perhaps others). Before you stop reading this as simply "we know Windows does not perform well", I should point out that this does not occur when the client is Windows or Linux, nor when the server is on the same Windows box but is IIS or Tomcat (standalone)! Some rough download speeds: recent Apache 1.3.x on Windows: client on Solaris (8): 80K/sec client on Linux or Windows: 8MB/sec recent Apache 2.0.x on Windows: client on Solaris (8): 120K/sec client on Linux or Windows: 8MB/sec IIS on Windows any client tried: 8-9 MB/sec Tomcat (standalone) on Windows any client tried: ~8MB/sec Oddly Apache performance was around 1MB/sec when the request was routed through it to mod_jk to Tomcat -- which is far worse than the 8MB/sec, but far better than 80-120K/sec. I have filed bugs (12097 and 12099) against Apache 1.3 and 2.0 on these issues as it is fairly clear that Apache is doing something wrong that both IIS and Tomcat manage not to do. -- Jess Holle
Re: more on the charter (was: El-Kabong -- HTML Parser)
At 12:43 PM -0700 8/27/02, Greg Stein wrote: > >> > APR is whatever we want it to be. If we start building things on > >You bet! Well, it depends on how far you want to take the statement "whatever we want it to be" :) *duck* > > > top of APR that are functionally distinct from other projects under >> > the ASF, then I believe it makes sense to keep them as subprojects >> > of APR. Either we extend the meaning of APR to mean "any portable >> > libraries" or we take away the "server" in "HTTP Server Project". > >Per the Board, we are *already* about portable libraries. > APR has evolved... Not only is the project about a portable runtime library, but also generic portable libraries as well. I also find this a Good Thing. Growth is good. But it isn't, and shouldn't be, a drop-box for every library or suite of routines that comes down the path (not that anyone is saying that it is or will be). Regarding specifically e-k, as a html parser, it's got more a family tie, IMO, to the HTTP server project, than APR. I think it fits in better among libapreq than in the APR world, mostly because it's focused towards the web server and web server functionality. Would it destroy APR to fold e-k into it... I don't think so. Is there a better place under the ASF than in APR? Maybe :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: El-Kabong -- HTML Parser
fyi, I've already emailed Jon about doing a review. I would recommend that at least one other review it, too. On Tue, Aug 27, 2002 at 10:28:18AM -0700, Jon Travis wrote: > Well, if people are agreeing to this, can we get someone involved > in the HTTPD project (non-Covalent affiliated) to review and > approve/decline? Volunteers? > > -- Jon >... -- Greg Stein, http://www.lyra.org/
Re: authentication rewrite
Hi - >-- Original Message -- >Reply-To: [EMAIL PROTECTED] >Date: Tue, 27 Aug 2002 09:51:09 -0700 >From: Justin Erenkrantz <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: authentication rewrite > > >On Tue, Aug 27, 2002 at 10:12:43AM -0400, [EMAIL PROTECTED] wrote: >Without seeing use cases, it's hard to know what people want. For >now, I can only go off of what we have now. > >(I'm hoping that people who write third-party auth engines speak >up now and point out how this API could make it better for them if >it only did XYZ.) welp, that is why i spoke up i suppose. A use case is the desire for ldap auth to allow for property requirements. e.g. Require ldap_prop department=engineering for example (that's hypothetical syntax). You would need to add a new function to the callback structure validate_property(name, value) or something. While this would be easy to add (and would be reusable by various database auth modules) - it is just an example of many possible requirements. you could add another callback function to your backend structure - this function would be register_requirement_handler(requirement_name, function). In your switch statement "valid-user", "user", "group", it could fall through by looking for a handler that has been registered for that requirement. That handler would simply be passed the rest of the requirement string - and would return 0,1. I could send a patch to your current code if that would be clearer - its really pretty simple, but would allow the backends to get at least a little more powerful (and would solve the ldap_prop case i illustrated above sterling
Re: authentication rewrite
a big +1... On Mon, Aug 26, 2002 at 11:44:32PM -0700, Justin Erenkrantz wrote: >... > My point is that I need to add another front end authentication > module (namely within mod_dav). I think it'd be pointless to > duplicate all of the backend work done in mod_auth* so that > mod_dav can authenticate users. Eh? I thought you wanted *access* to the user information, not to perform authentication. And/or maybe you need the data for authorization? > The current authentication API > can't work as it combines the front and back-ends. The answer we > give to people is, "cut-and-paste." Ick. Therefore, yes, I think > we have to introduce another level as what we have now is > insufficient. Absolutely. I recall Ken and I talking about this kind of separation over three years ago. >... > And, it doesn't mandate that third-party modules have to move to this > scheme - it's opt-in. Yup. Unless you kill the helper functions from server/protocol.c. :-) >... > Of course, I would expect the API to become better as we play with it > more and determine what is missing. However, this API is currently > sufficient for the two providers that are already included - enough > so that I think future work warrants inclusion in the tree. As we Absolutely. You have to start somewhere. If you want for perfection, then you'll never get anything done. Some random nits/comments about the code itself: * get_user_groups() should return a hash rather than a table, right? Or do you truly need the case insensitively? If so, then couldn't you mandate the provider insert lower-cased values, and then you can look them up that way? * need the various guards/wrappers in mod_auth.h * some of your files refer to "Portions of this software based on..." I seriously doubt that is true for your new files :-) [altho it probably *is* true for mod_auth derivatives] * mod_auth_file/dbm.c: the module rec has a comment about "command apr_table_t"... it isn't a apr_table_t. some old search/replace comment? * mod_auth_dbm.c: obsolete comment at the top (between license and first #include line) * mod_auth_file.c: constify the values in auth_file_config_rec Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: adding options to apachectl
On Tue, Aug 27, 2002 at 02:15:16PM -0400, Dave Hill wrote: > I would like to propose a change to apachectl (for 2.0 although > work with 1.3 as well) > > I like using toggles in the default httpd.conf files > I provide to customers (for things like Tomcat connectors, PHP...), > The problem with the toggles is getting them on the command line. I really like the idea of controlling sections of configs with IfDefines, and then supplying -Dfoo defines on the command line, but I don't think these should be controlled by an environment variable. The only reason for this is that is allows for unexpected side-effects. I'd rather see us adapt the apachectl script to allow for arbitrary -D parameters in addition to the start|stop|blah commands. This also would work nicely instead of using all over the place to optionally include features. -aaron
Re: Is anybody getting CVS commit messages?
I see them On Tue, 27 Aug 2002 [EMAIL PROTECTED] wrote: > > I realized earlier today that I haven't been seeing commit messages. > > Is anybody getting these messages? > > Ryan > > -- > > ___ > Ryan Bloom[EMAIL PROTECTED] > 550 Jean St > Oakland CA 94610 > --- >
Is anybody getting CVS commit messages?
I realized earlier today that I haven't been seeing commit messages. Is anybody getting these messages? Ryan -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
adding options to apachectl
Hi all, I would like to propose a change to apachectl (for 2.0 although work with 1.3 as well) I like using toggles in the default httpd.conf files I provide to customers (for things like Tomcat connectors, PHP...), The problem with the toggles is getting them on the command line. With a very minor generic change to apachectl the options can be put into bin/envvars (which is already read by apachectl) and added to the invocation of httpd. The nice thing about this approach is that you don't have to hack apachectl with specific options, and envvars is much much easier to parse & modify. If HTTPD_OPTIONS is not set, it defaults to blank which is just fine. Proposed patch follows: regards, Dave Hill *** apachectl.orig Tue Aug 27 13:58:52 2002 --- apachectl Tue Aug 27 14:02:30 2002 *** *** 54,68 case $ARGV in start|stop|restart|graceful) ! $HTTPD -k $ARGV ERROR=$? ;; startssl|sslstart|start-SSL) ! $HTTPD -k start -DSSL ERROR=$? ;; configtest) ! $HTTPD -t ERROR=$? ;; status) --- 54,68 case $ARGV in start|stop|restart|graceful) ! $HTTPD -k $ARGV $HTTPD_OPTIONS ERROR=$? ;; startssl|sslstart|start-SSL) ! $HTTPD -k start -DSSL $HTTPD_OPTIONS ERROR=$? ;; configtest) ! $HTTPD -t $HTTPD_OPTIONS ERROR=$? ;; status) *** *** 72,78 $LYNX $STATUSURL ;; *) ! $HTTPD $ARGV ERROR=$? esac --- 72,78 $LYNX $STATUSURL ;; *) ! $HTTPD $ARGV $HTTPD_OPTIONS ERROR=$? esac
RE: relative log file locations in 2.0.41-dev
> can you check the latest CVS version now and see if it fixes your problem? Fixes the startup failure I was seeing earlier this a.m. on Win32. Allan
Re: El-Kabong -- HTML Parser
> I can't publicly post the source under the ASF license until it has been > accepted (which is a chicken & egg issue). I can, however, distribute > to individuals on a restricted basis for evaluation for acceptance. There is little (except for a few upset board members) stopping Covalent of posting the code somewhere publicly under an ASF (style) license. This has been done often in the past by the likes of IBM, Covalent and SUN at various moments. Either using an ASF license, an ASF style licecense or a BSD-ish license. Alternatively putting no or a simple (c) on it; and no further distribution clauses will make it simple 'look' but done re-distribute code. Which allows anyone to look at it - but would not allow anyone to re-distribute it. Getting that code accepted into the ASF repositories is another story. Dw
Re: relative log file locations in 2.0.41-dev
Ask Bjoern Hansen wrote: > It seems like the latest httpd from CVS doesn't prepend ServerRoot > to to log paths. If I start the httpd like this, > > /home/perl/apache2/bin/httpd -d /home/web/front/ -k start -e debug > > I get an error that it can't open logs/error_log. > > If I chdir to /home/web/front/ I don't get an error message, but the > httpd silently just exits. > > If I change the log paths to absolute paths everything works fine. > > > - ask > ask/Jeff can you check the latest CVS version now and see if it fixes your problem?
Re: [PROPOSAL] Move AUTH_LDAP to /experimental (was: authentication rewrite)
Graham Leggett wrote: > Aaron Bannert wrote: > >> I would *love* to see this happen. I think a decoupling of modules >> from the core httpd server would give us many benefits: > > > True, but keeping functionality out of the server until such a system > exists is a mistake. Any CPAN style system should not hold up > development of the server. > agreed. and when such a system exists, the modules could be moved over to it. in the mean time they should go into the core > Regards, > Graham
Re: authentication rewrite
> Yeah, you hit the problem with stacking - authoritative. I'm not > sure how useful having multiple backends could be. I'd almost > suggest that something like a PAM backend would be much better and > allows a fairly standard configuration. (I know Dirk has a PAM It is integrated into the PAM project at the sourceforge. I've worked with the author(s) to give it an ASF style license - and they'd be more than happy to share/donate the module to the ASF. Issues with respect to Maintenace and Community would of course still be there and I've not looked into that. > module somewhere.) That removes the stacking component entirely if > we supported PAM. Actually - because of PAM, especially remote PAM into radius or tacacs, stacking at the very least a file based 'backup' auth provider in the tree (preferably independend of PAM - which can have finicky failure mode) is invaluable in operational environments in my experience. Dw
Re: El-Kabong -- HTML Parser
Jon Travis wrote: > Well, if people are agreeing to this, can we get someone involved > in the HTTPD project (non-Covalent affiliated) to review and > approve/decline? Volunteers? > I can't publicly post the source under the ASF license until it has been > accepted (which is a chicken & egg issue). I can, however, distribute > to individuals on a restricted basis for evaluation for acceptance. I don't think that is really the "ASF Way". It would be rather unusual for Apache to accept code without a public review. The only cases I can think of are security-related. Why don't you just post the code under a "Copyright Covalent, all rights reserved", with a promise to relicense if it is accepted. Joshua.
Re: El-Kabong -- HTML Parser
Well, if people are agreeing to this, can we get someone involved in the HTTPD project (non-Covalent affiliated) to review and approve/decline? Volunteers? -- Jon On Tue, Aug 27, 2002 at 01:22:03PM -0400, Jim Jagielski wrote: > I didn't mean in the same tree at all! :) > > But, as you said, a subproj under HTTPD > > Jon Travis wrote: > > > > I personally think it belongs as some kind of sub-project to httpd, but > > not in the same tree. > > > > -- Jon > > > > > > On Tue, Aug 27, 2002 at 12:43:17PM -0400, Jim Jagielski wrote: > > > Aaron Bannert wrote: > > > > > > > > On Tue, Aug 27, 2002 at 11:02:47AM -0400, Ryan Bloom wrote: > > > > > I would prefer that this became it's own project either under the httpd > > > > > project or the APR project. I don't believe that it should be a part of > > > > > the APR-util library however. > > > > > > > > The functionality provided by el-kabong seems like a good fit within APR. > > > > I think it would be fine if el-kabong became a new subproject of APR. > > > > > > > > > > Personally, I think it's very cool that E-K is being folded into the > > > ASF. I think the httpd project is a better fit however, simply > > > because APR should be protocol ignorant. > > > > > > -- > > > === > > >Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ > > > "A society that will trade a little liberty for a little order > > > will lose both and deserve neither" - T.Jefferson > > > > > -- > === >Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ > "A society that will trade a little liberty for a little order > will lose both and deserve neither" - T.Jefferson
Apache httpd-ldap modules on AIX?
Has anyone gotten the Apache httpd-ldap sub-project modules to load into Apache 2.0 on AIX? I've gotten them to build just fine (and gotten them to run just fine on Windows [after a patch] and Solaris), but I Apache (2.0.40) fails to load mod_ldap.so on AIX. I'm only getting the "Syntax error..." and "Cannot load ... mod_ldap.so ..." lines -- no further specifics e.g. regarding missing symbols or libraries, so I'm baffled. Any pointers would be much appreciated! -- Jess Holle [EMAIL PROTECTED]
Re: El-Kabong -- HTML Parser
On Tue, Aug 27, 2002 at 09:47:58AM -0700, daniel wrote: > > A couple of notes on the parser: > - It is pretty lightweight and self contained > - This HTML parser can be used for a multitude of applications, in Apache > 2.0 filter modules. The filter processes content generated by Apache or proxied > content and can rewrite URLs embedded in HTML pages: > a) URL rewriting on the fly for cookieless tracking and single sign-on > b) Allow ProxyPassReverse to modify not only HTTP headers but look inside > proxied content and rewrite hardcoded URLs > c) Strip banners or malicious javascript before it reaches the client > > Those are some possibilities that having a fast, lightweight parser allows. > Jon, maybe you can post the source somewhere so people can have a look and > play with it > > Daniel I can't publicly post the source under the ASF license until it has been accepted (which is a chicken & egg issue). I can, however, distribute to individuals on a restricted basis for evaluation for acceptance. -- Jon
Apache httpd-ldap module issue
The Apache 2 modules in the httpd-ldap sub-project (which should be moved
into 'experimental' in my opinion and have standard MSVC++ projects created,
etc -- though I have no vote) crash on Windows 2000 in Apache 2.0.40. [Yes,
I'll file a bug as appropriate.]
The issue is use of uninitialized memory in util_ldap_cache_init() [in util_ldap_cache.c].
This routine declares a variable on stack, 'rmm_lock', and passes it to
apr_rmm_init() without initializing it. apr_rmm_init() expects this argument
to be initialized and causes a later crash on Windows as a result of finding
random gargly-gook in this structure and interpretting it in such a way that
does not match the reality of the situation.
My patch (sorry I'm new at this and don't know how to generate proper patches
:-( ) is to no longer declare this variable and pass NULL to apr_rmm_init()
in its place -- as apr_rmm_init() can take a NULL for this argument. This
seems to work fine on Windows and Solaris -- though I can't get this module
to load on AIX (no, I've not yet tried the original code)
The line are (in patch pseudo-syntax):
Lines 293-297:
apr_status_t util_ldap_cache_init(apr_pool_t *pool, apr_size_t
reqsize)
{
- apr_anylock_t rmm_lock;
#if APR_HAS_SHARED_MEMORY
and lines 305-308:
/* This will create a rmm "handler" to get into the shared
memory area */
- apr_rmm_init(&util_ldap_rmm, &rmm_lock,
+ apr_rmm_init(&util_ldap_rmm, NULL,
(void *)apr_shm_baseaddr_get(util_ldap_shm), reqsize,
pool);
#endif
The only alternative that I see is to add a call to initialize 'rmm_lock',
but from my brief scan it would appear that passing null is a more efficient
way of accomplishing the same thing.
Any comments?
--
Jess Holle
Re: [PROPOSAL] Move AUTH_LDAP to /experimental (was: authenticationrewrite)
Aaron Bannert wrote: > I would *love* to see this happen. I think a decoupling of modules > from the core httpd server would give us many benefits: True, but keeping functionality out of the server until such a system exists is a mistake. Any CPAN style system should not hold up development of the server. Regards, Graham -- - [EMAIL PROTECTED] "There's a moon over Bourbon Street tonight..."
Re: El-Kabong -- HTML Parser
A couple of notes on the parser: - It is pretty lightweight and self contained - This HTML parser can be used for a multitude of applications, in Apache 2.0 filter modules. The filter processes content generated by Apache or proxied content and can rewrite URLs embedded in HTML pages: a) URL rewriting on the fly for cookieless tracking and single sign-on b) Allow ProxyPassReverse to modify not only HTTP headers but look inside proxied content and rewrite hardcoded URLs c) Strip banners or malicious javascript before it reaches the client Those are some possibilities that having a fast, lightweight parser allows. Jon, maybe you can post the source somewhere so people can have a look and play with it Daniel On Mon, Aug 26, 2002 at 08:32:16PM -0700, Jon Travis wrote: > Hi all... > Jon Travis here... > > Covalent has written a pretty keen HTML parser (called el-kabong) > which we'd like to offer to the ASF for inclusion in APR-util (or > whichever other umbrella it fits under.) It's faster than > anything I can find, provides a SAX stylee interface, uses > APR for most of its operations (hash tables, etc.), and has a > pretty nice testsuite. We use it in our code to re-write HTML on > the fly. I would be the initial maintainer of the code. > > Please voice any interest, thanks. > > -- Jon -- Teach Yourself Apache 2 -- http://apacheworld.org/ty24/
Re: authentication rewrite
On Tue, Aug 27, 2002 at 10:12:43AM -0400, [EMAIL PROTECTED] wrote: > than the current AAA modules. In a 'require group' world, it is very nice > to abstract this stuff out so backends can be re-used, and apache specific > logic can be centralized - as you have proposed. But it will be harder > to plug in backends that try to do more with requirements (of which there > really aren't many)- which is probably fine. Without seeing use cases, it's hard to know what people want. For now, I can only go off of what we have now. (I'm hoping that people who write third-party auth engines speak up now and point out how this API could make it better for them if it only did XYZ.) > 1) It looks like the 'AuthProvider' does not allow you to stack auth handlers. > I would be cool (if not critical :) if it was more of an AddAuthProvider > - then the basic auth handler loops through all providers that are added. > This way you could configure ldap and anon for a given location. > > 2) If you do allow stacking of providers like this, you need to also provide > the ability to specify which one is authoritative (if any). Yeah, you hit the problem with stacking - authoritative. I'm not sure how useful having multiple backends could be. I'd almost suggest that something like a PAM backend would be much better and allows a fairly standard configuration. (I know Dirk has a PAM module somewhere.) That removes the stacking component entirely if we supported PAM. But, yeah, I think we could implement multiple providers ourselves if we wanted to. > 3) maybe i'm missing something, but why did you rewrite ap_note_basic_auth_failure > and ap_get_basic_auth? assuming there was a reason, maybe a comment in > the code would help clarify it. I want to toss ap_note_basic_auth_failure and ap_get_basic_auth. That code doesn't belong in the server/protocol.c. Ideally, any modules that were using these functions could just implement a backend module. But, I don't think we want to have those exported going forward - the only reason they are exported is because our API sucked. -- justin
Re: [PROPOSAL] Move AUTH_LDAP to /experimental (was: authentication rewrite)
On Tue, Aug 27, 2002 at 12:44:35PM -0400, Joshua Slive wrote: > I would be happier with a good system for integrating non-core modules, > such as an apache-rollup or a CPAN/freebsd ports like system. BUT, since > nobody seems willing to step-up and create such a system, I think it > would be a mistake to prevent good modules from getting the wider > distribution that they can expect from the core distribution. Freezing > apache features to wait for some mythical system to appear would be a > mistake. I would *love* to see this happen. I think a decoupling of modules from the core httpd server would give us many benefits: - cleaner interface for module integration - independent lifecycles allow for independent and quicker development - well-defined module interfaces allow for easier 3rd party integration - ... How do we start? I think the first step would be to come up with a unified way to build 3rd party modules, as either a static module or a DSO, and allowing for complex multi-file/multi-directory/multi-library build dependencies. -aaron
Re: [PROPOSAL] Move AUTH_LDAP to /experimental (was: authenticationrewrite)
Graham Leggett wrote: > [EMAIL PROTECTED] wrote: > >> I am very much against putting more modules into the standard server. > > > I think such a decision should be based on whether it is desirable for > core Apache to offer certain features, not whether there are many or few > modules in the core. > > Remember that putting more modules into the server makes life easier for > end users. As long as those modules support a core set of functionality > that can be expected of a webserver, they should be included. +1 I would be happier with a good system for integrating non-core modules, such as an apache-rollup or a CPAN/freebsd ports like system. BUT, since nobody seems willing to step-up and create such a system, I think it would be a mistake to prevent good modules from getting the wider distribution that they can expect from the core distribution. Freezing apache features to wait for some mythical system to appear would be a mistake. (By the way, my +1 does not apply to ldap in particular. I haven't reviewed it technically, so I shouldn't vote on it.) Joshua.
Re: [PROPOSAL] Move AUTH_LDAP to /experimental (was: authentication rewrite)
On Tue, Aug 27, 2002 at 09:27:16AM -0600, Brad Nicholes wrote: > modules, I would like to propose that we move AUTH_LDAP out of it's own > project and into experimental. This will enable AUTH_LDAP to get more +1. Especially if the auth rewrite occurs, auth_ldap would become much simpler. -- justin
Re: [PROPOSAL] Move AUTH_LDAP to /experimental (was: authenticationrewrite)
[EMAIL PROTECTED] wrote: > I am very much against putting more modules into the standard server. I think such a decision should be based on whether it is desirable for core Apache to offer certain features, not whether there are many or few modules in the core. Remember that putting more modules into the server makes life easier for end users. As long as those modules support a core set of functionality that can be expected of a webserver, they should be included. Regards, Graham -- - [EMAIL PROTECTED] "There's a moon over Bourbon Street tonight..."
Re: Segmentation fault when downloading large files
At 07:53 AM 8/27/2002, Peter Van Biesen wrote:
>What should I call it then ? not-so-tiny-files ? 8-)
Nah... large or big files is just fine :-)
I'm guessing $$$s to OOOs [donuts] that your client is starting
some byteranges somewhere along the way. Try adding the bit
\"%{Range}i\" in one of your access log formats to see if this is
the case.
As I understand it today, proxy plus byteranges is totally borked.
Bill
Re: relative log file locations in 2.0.41-dev
Ask Bjoern Hansen wrote: > It seems like the latest httpd from CVS doesn't prepend ServerRoot > to to log paths. If I start the httpd like this, > > /home/perl/apache2/bin/httpd -d /home/web/front/ -k start -e debug > > I get an error that it can't open logs/error_log. > > If I chdir to /home/web/front/ I don't get an error message, but the > httpd silently just exits. > > If I change the log paths to absolute paths everything works fine. > > > - ask > looking at it now. serves me right for doing development on NT ;-)
Re: [PROPOSAL] Move AUTH_LDAP to /experimental (was: authenticationrewrite)
I am very much against putting more modules into the standard server. Ryan On Tue, 27 Aug 2002, Brad Nicholes wrote: >Now that 2.0.40 has been released and we are in development of .41 > and the fact that there has been a proposal for re-architecting the AUTH > modules, I would like to propose that we move AUTH_LDAP out of it's own > project and into experimental. This will enable AUTH_LDAP to get more > exposure as an external module, allow it to be included in future > releases of Apache 2 for testing and stabilization, and make sure that > it is not overlooked in future development. LDAP is an important > authentication method and should be supported in Apache. > > Brad > > Brad Nicholes > Senior Software Engineer > Novell, Inc., the leading provider of Net business solutions > http://www.novell.com > > >>> [EMAIL PROTECTED] Tuesday, August 27, 2002 8:53:19 AM >>> > Hi - > > Shouldn't a new thread be spawned for an(other) ldap vote (its deja vu > all > over again :) > > sterling > > >-- Original Message -- > >Reply-To: [EMAIL PROTECTED] > >Date: Tue, 27 Aug 2002 08:20:05 -0600 > >From: "Brad Nicholes" <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> > >Subject: Re: authentication rewrite > > > > > >+1 > > > >Brad Nicholes > >Senior Software Engineer > >Novell, Inc., the leading provider of Net business solutions > >http://www.novell.com > > > [EMAIL PROTECTED] Tuesday, August 27, 2002 4:20:43 AM >>> > >Justin Erenkrantz wrote: > > > >> Ideally, you could use the LDAP filters that most PAM > >implementations > >> use, but definitely allow the user to tweak them. I'd like to get > >> mod_auth_ldap ported to this, and if we move towards a > >provider-based > >> system, I think mod_auth_ldap should be moved back into the core. > >> (Namely because that's the preferred auth for DAV ACL support as it > >> is hierarchical.) > > > >I want to see auth_ldap moved into experimental so that it is > included > > > >in any work done on overhauling the auth stuff. > > > >Currently the code is receiving minimal exposure where it is. > > > >Regards, > >Graham > >-- > >- > >[EMAIL PROTECTED] > > "There's a moon > > over Bourbon Street > > tonight..." > > > > -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
[PROPOSAL] Move AUTH_LDAP to /experimental (was:authentication rewrite)
Now that 2.0.40 has been released and we are in development of .41 and the fact that there has been a proposal for re-architecting the AUTH modules, I would like to propose that we move AUTH_LDAP out of it's own project and into experimental. This will enable AUTH_LDAP to get more exposure as an external module, allow it to be included in future releases of Apache 2 for testing and stabilization, and make sure that it is not overlooked in future development. LDAP is an important authentication method and should be supported in Apache. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com >>> [EMAIL PROTECTED] Tuesday, August 27, 2002 8:53:19 AM >>> Hi - Shouldn't a new thread be spawned for an(other) ldap vote (its deja vu all over again :) sterling >-- Original Message -- >Reply-To: [EMAIL PROTECTED] >Date: Tue, 27 Aug 2002 08:20:05 -0600 >From: "Brad Nicholes" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> >Subject: Re: authentication rewrite > > >+1 > >Brad Nicholes >Senior Software Engineer >Novell, Inc., the leading provider of Net business solutions >http://www.novell.com > [EMAIL PROTECTED] Tuesday, August 27, 2002 4:20:43 AM >>> >Justin Erenkrantz wrote: > >> Ideally, you could use the LDAP filters that most PAM >implementations >> use, but definitely allow the user to tweak them. I'd like to get >> mod_auth_ldap ported to this, and if we move towards a >provider-based >> system, I think mod_auth_ldap should be moved back into the core. >> (Namely because that's the preferred auth for DAV ACL support as it >> is hierarchical.) > >I want to see auth_ldap moved into experimental so that it is included > >in any work done on overhauling the auth stuff. > >Currently the code is receiving minimal exposure where it is. > >Regards, >Graham >-- >- >[EMAIL PROTECTED] > "There's a moon > over Bourbon Street > tonight..." >
Re: authentication rewrite
Hi - Shouldn't a new thread be spawned for an(other) ldap vote (its deja vu all over again :) sterling >-- Original Message -- >Reply-To: [EMAIL PROTECTED] >Date: Tue, 27 Aug 2002 08:20:05 -0600 >From: "Brad Nicholes" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> >Subject: Re: authentication rewrite > > >+1 > >Brad Nicholes >Senior Software Engineer >Novell, Inc., the leading provider of Net business solutions >http://www.novell.com > [EMAIL PROTECTED] Tuesday, August 27, 2002 4:20:43 AM >>> >Justin Erenkrantz wrote: > >> Ideally, you could use the LDAP filters that most PAM >implementations >> use, but definitely allow the user to tweak them. I'd like to get >> mod_auth_ldap ported to this, and if we move towards a >provider-based >> system, I think mod_auth_ldap should be moved back into the core. >> (Namely because that's the preferred auth for DAV ACL support as it >> is hierarchical.) > >I want to see auth_ldap moved into experimental so that it is included > >in any work done on overhauling the auth stuff. > >Currently the code is receiving minimal exposure where it is. > >Regards, >Graham >-- >- >[EMAIL PROTECTED] > "There's a moon > over Bourbon Street > tonight..." >
Re: authentication rewrite
+1 Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com >>> [EMAIL PROTECTED] Tuesday, August 27, 2002 4:20:43 AM >>> Justin Erenkrantz wrote: > Ideally, you could use the LDAP filters that most PAM implementations > use, but definitely allow the user to tweak them. I'd like to get > mod_auth_ldap ported to this, and if we move towards a provider-based > system, I think mod_auth_ldap should be moved back into the core. > (Namely because that's the preferred auth for DAV ACL support as it > is hierarchical.) I want to see auth_ldap moved into experimental so that it is included in any work done on overhauling the auth stuff. Currently the code is receiving minimal exposure where it is. Regards, Graham -- - [EMAIL PROTECTED] "There's a moon over Bourbon Street tonight..."
Re: authentication rewrite
Hi Justin - >-- Original Message -- >Reply-To: [EMAIL PROTECTED] >Date: Mon, 26 Aug 2002 23:44:32 -0700 >From: Justin Erenkrantz <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: authentication rewrite > >My point is that I need to add another front end authentication >module (namely within mod_dav). I think it'd be pointless to >duplicate all of the backend work done in mod_auth* so that >mod_dav can authenticate users. The current authentication API >can't work as it combines the front and back-ends. The answer we >give to people is, "cut-and-paste." Ick. Therefore, yes, I think >we have to introduce another level as what we have now is >insufficient. I understand your point, and I think its a good one. I just wanted to raise a concern (which I still think is important to think about). about a year and a half ago I abstracted the auth stuff in a similar way - In my case, however, I wanted the back ends to have much richer authorization functionality than the current AAA modules. In a 'require group' world, it is very nice to abstract this stuff out so backends can be re-used, and apache specific logic can be centralized - as you have proposed. But it will be harder to plug in backends that try to do more with requirements (of which there really aren't many)- which is probably fine. >In my vision, the LDAP module would have its own directives/options >to specify what it returns. So, I don't think this is a big concern. > >I'd imagine something like: > >AuthProvider ldap >AuthLDAPServer ldap.example.com >AuthLDAPBase o=example.com >AuthLDAPUserSearch (username=%s) >AuthLDAPGroupSearch (groupmember=%s) here's a couple of comments on the implementation: 1) It looks like the 'AuthProvider' does not allow you to stack auth handlers. I would be cool (if not critical :) if it was more of an AddAuthProvider - then the basic auth handler loops through all providers that are added. This way you could configure ldap and anon for a given location. 2) If you do allow stacking of providers like this, you need to also provide the ability to specify which one is authoritative (if any). 3) maybe i'm missing something, but why did you rewrite ap_note_basic_auth_failure and ap_get_basic_auth? assuming there was a reason, maybe a comment in the code would help clarify it. hope this helps. sterling
Re: CacheOn directive
Taking those sentiments into account ;), if there are no *other* reasons to keep CacheOn (since it does nothing) I will be committing a fix this afternoon that removes it. Jim Jagielski wrote: > I kinda like it... reminds me of the Human Torch: Flame On! :) > > Ask Bjoern Hansen wrote: > >> >>"CacheOn on" sounds pretty silly. Wouldn't it be better if it was >>"CacheOn yes" or just "Cache on"? :-) >> >> >> - ask >> >>-- >>ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do(); >> >> > > -- Paul J. Reder --- "The strength of the Constitution lies entirely in the determination of each citizen to defend it. Only if every single citizen feels duty bound to do his share in this defense are the constitutional rights secure." -- Albert Einstein
Re: Segmentation fault when downloading large files
On Tue, 27 Aug 2002, Peter Van Biesen wrote: > > APR's concept of a "large file" (which is the concept used by file > > buckets, btw) is >2GB. > > What should I call it then ? not-so-tiny-files ? 8-) hehehe I was just pointing out that < 70MB vs. > 70MB shouldn't make any difference as far as APR or APR-util are concerned. Can you give us a backtrace on the segfaulting child please? See http://httpd.apache.org/dev/debugging.html for tips on how to do that if you're not familiar with gdb. Thanks, Cliff
Re: mod_cache trouble
Will do. Ask Bjoern Hansen wrote: > On Tue, 27 Aug 2002, Paul J. Reder wrote: > > >>Are you using the most recent head build of 2.0? There was a >>fix applied recently to the header handling for mod_disk_cache. >> >>I am currently doing some work on the caching code, so I'll >>look into this. Please let me know if you are on the latest >>code. >> > > Yes, I am. Let me know when you have something you'd like me to > test. :-) > > > - ask > > -- Paul J. Reder --- "The strength of the Constitution lies entirely in the determination of each citizen to defend it. Only if every single citizen feels duty bound to do his share in this defense are the constitutional rights secure." -- Albert Einstein
Re: mod_cache trouble
On Tue, 27 Aug 2002, Paul J. Reder wrote: > Are you using the most recent head build of 2.0? There was a > fix applied recently to the header handling for mod_disk_cache. > > I am currently doing some work on the caching code, so I'll > look into this. Please let me know if you are on the latest > code. Yes, I am. Let me know when you have something you'd like me to test. :-) - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: CacheOn directive
I kinda like it... reminds me of the Human Torch: Flame On! :) Ask Bjoern Hansen wrote: > > > "CacheOn on" sounds pretty silly. Wouldn't it be better if it was > "CacheOn yes" or just "Cache on"? :-) > > > - ask > > -- > ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do(); > -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: mod_cache trouble
Are you using the most recent head build of 2.0? There was a
fix applied recently to the header handling for mod_disk_cache.
I am currently doing some work on the caching code, so I'll
look into this. Please let me know if you are on the latest
code.
Thanks,
Paul J. Reder
Ask Bjoern Hansen wrote:
> I am using the latest httpd from CVS.
>
> I can't get mod_disk_cache to cache anything but 301's.
>
> I suspect it's something related to the headers I (don't) send.
>
> $ lwp-request -e -d -S http://nntp.x.perl.org/
> GET http://nntp.x.perl.org/ --> 200 OK
> Connection: close
> Date: Tue, 27 Aug 2002 11:34:58 GMT
> Via: 1.0 nntp.x.perl.org
> Server: Apache/1.3.26 (Unix) mod_perl/1.27
> Content-Length: 1896
> Content-Type: text/html; charset=ISO-8859-1
>
>
> My httpd.conf looks like the following,
>
> LoadModule cache_module modules/mod_cache.so
> LoadModule disk_cache_module modules/mod_disk_cache.so
>
> [...]
>
>
> servername nntp.x.perl.org
> serveralias nntp.perl.org
>
> CacheOn on
> CacheRoot /home/web/front/cache/
> CacheSize 5
> CacheDefaultExpire 43200
> CacheEnable disk /
> CacheDirLevels 5
> CacheDirLength 3
>
> RewriteEngine On
> RewriteCond %{REQUEST_URI}!^/js/
> RewriteCond %{REQUEST_URI}!^/proxy-status
> RewriteRule (.*) http://localhost:8222$1 [P]
>
>
> [...]
>
> - ask
>
>
--
Paul J. Reder
---
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: CacheOn directive
In fact, the CacheOn directive simply sets a variable in the mod_cache data structure which is never checked. Is there any reason to keep this directive or can I go ahead and remove CacheOn and the code that sets and merges it (for no good reason)? Graham Leggett wrote: > Ask Bjoern Hansen wrote: > >> "CacheOn on" sounds pretty silly. Wouldn't it be better if it was >> "CacheOn yes" or just "Cache on"? :-) > > > Or another question: What does CacheOn do that CacheEnable doesn't > already do? > > Regards, > Graham -- Paul J. Reder --- "The strength of the Constitution lies entirely in the determination of each citizen to defend it. Only if every single citizen feels duty bound to do his share in this defense are the constitutional rights secure." -- Albert Einstein
Re: Segmentation fault when downloading large files
What should I call it then ? not-so-tiny-files ? 8-) Cliff Woolley wrote: > > On Tue, 27 Aug 2002, Graham Leggett wrote: > > > The filter code behaves differently depending on where the data is > > coming from, eg an area in memory, or a file on a disk. As a result it > > is quite possible that a large file from disk works and a large file > > from proxy does not. > > APR's concept of a "large file" (which is the concept used by file > buckets, btw) is >2GB. > > --Cliff
Re: Segmentation fault when downloading large files
On Tue, 27 Aug 2002, Graham Leggett wrote: > The filter code behaves differently depending on where the data is > coming from, eg an area in memory, or a file on a disk. As a result it > is quite possible that a large file from disk works and a large file > from proxy does not. APR's concept of a "large file" (which is the concept used by file buckets, btw) is >2GB. --Cliff
Re: authentication rewrite
On Mon, 26 Aug 2002, Justin Erenkrantz wrote: > I need to be able to get at the authentication backends to implement > some DAV enhancements - namely DAV has its own authentication model > (DAV ACL support). My idea would be to allow mod_dav to reuse the > aaa backends and just implement the client-facing bits there. > > Therefore, I've begun to split up the authentication frontends > and backends. I've used the DAV philosophy by having providers > and registering them. http://www.apache.org/~dirkx/aaa.tgz Has another bit of simplicataion in it. Which may be useful. As to the propsal below - see other message. Dw.
Re: CacheOn directive
Ask Bjoern Hansen wrote: > "CacheOn on" sounds pretty silly. Wouldn't it be better if it was > "CacheOn yes" or just "Cache on"? :-) Or another question: What does CacheOn do that CacheEnable doesn't already do? Regards, Graham -- - [EMAIL PROTECTED] "There's a moon over Bourbon Street tonight..."
mod_log_config changes break httpd?
Apache won't initialize... look at the name passed when
opening/creating the file:
open("logs/access_log", O_WRONLY|O_APPEND|O_CREAT, 0666) = -1 ENOENT (No such file or
directory)
gettimeofday({1030448472, 125843}, NULL) = 0
write(2, "[Tue Aug 27 11:41:12 2002] [erro"..., 115) = 115
_exit(1)
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
CacheOn directive
"CacheOn on" sounds pretty silly. Wouldn't it be better if it was "CacheOn yes" or just "Cache on"? :-) - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
mod_cache trouble
I am using the latest httpd from CVS.
I can't get mod_disk_cache to cache anything but 301's.
I suspect it's something related to the headers I (don't) send.
$ lwp-request -e -d -S http://nntp.x.perl.org/
GET http://nntp.x.perl.org/ --> 200 OK
Connection: close
Date: Tue, 27 Aug 2002 11:34:58 GMT
Via: 1.0 nntp.x.perl.org
Server: Apache/1.3.26 (Unix) mod_perl/1.27
Content-Length: 1896
Content-Type: text/html; charset=ISO-8859-1
My httpd.conf looks like the following,
LoadModule cache_module modules/mod_cache.so
LoadModule disk_cache_module modules/mod_disk_cache.so
[...]
servername nntp.x.perl.org
serveralias nntp.perl.org
CacheOn on
CacheRoot /home/web/front/cache/
CacheSize 5
CacheDefaultExpire 43200
CacheEnable disk /
CacheDirLevels 5
CacheDirLength 3
RewriteEngine On
RewriteCond %{REQUEST_URI}!^/js/
RewriteCond %{REQUEST_URI}!^/proxy-status
RewriteRule (.*) http://localhost:8222$1 [P]
[...]
- ask
--
ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
relative log file locations in 2.0.41-dev
It seems like the latest httpd from CVS doesn't prepend ServerRoot to to log paths. If I start the httpd like this, /home/perl/apache2/bin/httpd -d /home/web/front/ -k start -e debug I get an error that it can't open logs/error_log. If I chdir to /home/web/front/ I don't get an error message, but the httpd silently just exits. If I change the log paths to absolute paths everything works fine. - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: Segmentation fault when downloading large files
Peter Van Biesen wrote: > However, when downloading a large file from the server itself ( not > using the proxy ), works fine ... either its a problem in the proxy or a > timeout somewhere ( locally is a lot faster ). The proxy is very "dumb" code, it relies almost exclusively on the filter code to do everything. As a result it's very unlikely this problem is in proxy. The filter code behaves differently depending on where the data is coming from, eg an area in memory, or a file on a disk. As a result it is quite possible that a large file from disk works and a large file from proxy does not. Regards, Graham -- - [EMAIL PROTECTED] "There's a moon over Bourbon Street tonight..."
Re: Segmentation fault when downloading large files
However, when downloading a large file from the server itself ( not using the proxy ), works fine ... either its a problem in the proxy or a timeout somewhere ( locally is a lot faster ). Peter. Dirk-Willem van Gulik wrote: > > This look like a filter issue I've seen before; but never could not quite > reproduce. You may want to take this to [EMAIL PROTECTED]; as this is > most likely related to the filters in apache; and not proxy specific. > > Dw. > > On Tue, 27 Aug 2002, Peter Van Biesen wrote: > > > Hello, > > > > I'm using an apache 2.0.39 on a HPUX 11.0 system as a webserver/proxy. > > When I try to download large files through the proxy, I get the > > following error : > > > > [Tue Aug 27 11:44:08 2002] [debug] proxy_http.c(109): proxy: HTTP: > > canonicalising URL > > //download.microsoft.com/download/win2000platform/SP/SP3/NT5/EN-US/W2Ksp3.exe > > [Tue Aug 27 11:44:08 2002] [debug] mod_proxy.c(442): Trying to run > > scheme_handler against proxy > > [Tue Aug 27 11:44:08 2002] [debug] proxy_http.c(1051): proxy: HTTP: > > serving URL > > http://download.microsoft.com/download/win2000platform/SP/SP3/NT5/EN-US/W2Ksp3.exe > > [Tue Aug 27 11:44:08 2002] [debug] proxy_http.c(221): proxy: HTTP > > connecting > > http://download.microsoft.com/download/win2000platform/SP/SP3/NT5/EN-US/W2Ksp3.exe > > to download.microsoft.com:80 > > [Tue Aug 27 11:44:08 2002] [debug] proxy_util.c(1164): proxy: HTTP: fam > > 2 socket created to connect to vlafo3.vlafo.be > > [Tue Aug 27 11:44:09 2002] [debug] proxy_http.c(370): proxy: socket is > > connected > > [Tue Aug 27 11:44:09 2002] [debug] proxy_http.c(404): proxy: connection > > complete to 193.190.145.66:80 (vlafo3.vlafo.be) > > [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline > > = Date: Tue, 27 Aug 2002 09:44:09 GMT > > [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline > > = Server: Microsoft-IIS/5.0 > > [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline > > = Content-Type: application/octet-stream > > [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline > > = Accept-Ranges: bytes > > [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline > > = Last-Modified: Tue, 23 Jul 2002 16:23:09 GMT > > [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline > > = ETag: "f2138b3b6532c21:8f9" > > [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline > > = Via: 1.1 download.microsoft.com > > [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline > > = Transfer-Encoding: chunked > > [Tue Aug 27 11:44:09 2002] [debug] proxy_http.c(893): proxy: start body > > send > > [Tue Aug 27 11:57:45 2002] [notice] child pid 7099 exit signal > > Segmentation fault (11) > > > > I'm sorry for the example ... ;-)) > > > > Anyway, I've tried on several machine that are configured differently ( > > swap, memory ), but the download stops always around 70 Mb. Does anybody > > have an idea what's wrong ? Is there a core I could gdb ( I didn't find > > any ) ? > > > > Thanks ! > > > > Peter. > >
[Fwd: Segmentation fault when downloading large files]
Hi, as this is probably not due to the proxy, I'm reposting this here. Can anybody help me ? Thanks ! Peter. --- Begin Message --- Hello, I'm using an apache 2.0.39 on a HPUX 11.0 system as a webserver/proxy. When I try to download large files through the proxy, I get the following error : [Tue Aug 27 11:44:08 2002] [debug] proxy_http.c(109): proxy: HTTP: canonicalising URL //download.microsoft.com/download/win2000platform/SP/SP3/NT5/EN-US/W2Ksp3.exe [Tue Aug 27 11:44:08 2002] [debug] mod_proxy.c(442): Trying to run scheme_handler against proxy [Tue Aug 27 11:44:08 2002] [debug] proxy_http.c(1051): proxy: HTTP: serving URL http://download.microsoft.com/download/win2000platform/SP/SP3/NT5/EN-US/W2Ksp3.exe [Tue Aug 27 11:44:08 2002] [debug] proxy_http.c(221): proxy: HTTP connecting http://download.microsoft.com/download/win2000platform/SP/SP3/NT5/EN-US/W2Ksp3.exe to download.microsoft.com:80 [Tue Aug 27 11:44:08 2002] [debug] proxy_util.c(1164): proxy: HTTP: fam 2 socket created to connect to vlafo3.vlafo.be [Tue Aug 27 11:44:09 2002] [debug] proxy_http.c(370): proxy: socket is connected [Tue Aug 27 11:44:09 2002] [debug] proxy_http.c(404): proxy: connection complete to 193.190.145.66:80 (vlafo3.vlafo.be) [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline = Date: Tue, 27 Aug 2002 09:44:09 GMT [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline = Server: Microsoft-IIS/5.0 [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline = Content-Type: application/octet-stream [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline = Accept-Ranges: bytes [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline = Last-Modified: Tue, 23 Jul 2002 16:23:09 GMT [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline = ETag: "f2138b3b6532c21:8f9" [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline = Via: 1.1 download.microsoft.com [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline = Transfer-Encoding: chunked [Tue Aug 27 11:44:09 2002] [debug] proxy_http.c(893): proxy: start body send [Tue Aug 27 11:57:45 2002] [notice] child pid 7099 exit signal Segmentation fault (11) I'm sorry for the example ... ;-)) Anyway, I've tried on several machine that are configured differently ( swap, memory ), but the download stops always around 70 Mb. Does anybody have an idea what's wrong ? Is there a core I could gdb ( I didn't find any ) ? Thanks ! Peter. --- End Message ---
Re: Segmentation fault when downloading large files
This look like a filter issue I've seen before; but never could not quite reproduce. You may want to take this to [EMAIL PROTECTED]; as this is most likely related to the filters in apache; and not proxy specific. Dw. On Tue, 27 Aug 2002, Peter Van Biesen wrote: > Hello, > > I'm using an apache 2.0.39 on a HPUX 11.0 system as a webserver/proxy. > When I try to download large files through the proxy, I get the > following error : > > [Tue Aug 27 11:44:08 2002] [debug] proxy_http.c(109): proxy: HTTP: > canonicalising URL > //download.microsoft.com/download/win2000platform/SP/SP3/NT5/EN-US/W2Ksp3.exe > [Tue Aug 27 11:44:08 2002] [debug] mod_proxy.c(442): Trying to run > scheme_handler against proxy > [Tue Aug 27 11:44:08 2002] [debug] proxy_http.c(1051): proxy: HTTP: > serving URL > http://download.microsoft.com/download/win2000platform/SP/SP3/NT5/EN-US/W2Ksp3.exe > [Tue Aug 27 11:44:08 2002] [debug] proxy_http.c(221): proxy: HTTP > connecting > http://download.microsoft.com/download/win2000platform/SP/SP3/NT5/EN-US/W2Ksp3.exe > to download.microsoft.com:80 > [Tue Aug 27 11:44:08 2002] [debug] proxy_util.c(1164): proxy: HTTP: fam > 2 socket created to connect to vlafo3.vlafo.be > [Tue Aug 27 11:44:09 2002] [debug] proxy_http.c(370): proxy: socket is > connected > [Tue Aug 27 11:44:09 2002] [debug] proxy_http.c(404): proxy: connection > complete to 193.190.145.66:80 (vlafo3.vlafo.be) > [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline > = Date: Tue, 27 Aug 2002 09:44:09 GMT > [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline > = Server: Microsoft-IIS/5.0 > [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline > = Content-Type: application/octet-stream > [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline > = Accept-Ranges: bytes > [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline > = Last-Modified: Tue, 23 Jul 2002 16:23:09 GMT > [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline > = ETag: "f2138b3b6532c21:8f9" > [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline > = Via: 1.1 download.microsoft.com > [Tue Aug 27 11:44:09 2002] [debug] proxy_util.c(444): proxy: headerline > = Transfer-Encoding: chunked > [Tue Aug 27 11:44:09 2002] [debug] proxy_http.c(893): proxy: start body > send > [Tue Aug 27 11:57:45 2002] [notice] child pid 7099 exit signal > Segmentation fault (11) > > I'm sorry for the example ... ;-)) > > Anyway, I've tried on several machine that are configured differently ( > swap, memory ), but the download stops always around 70 Mb. Does anybody > have an idea what's wrong ? Is there a core I could gdb ( I didn't find > any ) ? > > Thanks ! > > Peter. >
Re: authentication rewrite
Justin Erenkrantz wrote: > Ideally, you could use the LDAP filters that most PAM implementations > use, but definitely allow the user to tweak them. I'd like to get > mod_auth_ldap ported to this, and if we move towards a provider-based > system, I think mod_auth_ldap should be moved back into the core. > (Namely because that's the preferred auth for DAV ACL support as it > is hierarchical.) I want to see auth_ldap moved into experimental so that it is included in any work done on overhauling the auth stuff. Currently the code is receiving minimal exposure where it is. Regards, Graham -- - [EMAIL PROTECTED] "There's a moon over Bourbon Street tonight..."
Re: [PATCH] fixes segfault in mod_cache (2.0.40)
Kris Verbeeck wrote: > Apache behaviour with this patch (or without mod_cache): > > The request: > > GET https://whatever.html HTTP/1.0 > > is equivalent to: > > GET / HTTP/1.0 > > I'm wondering whether this is the desired behaviour? This is > also the behaviour of a 1.3.x Apache. Maybe Apache should block > this kind of requests and return an error message?? This is correct: You are asking Apache to return the default page from a website called "whatever.html". As there is no virtual host configured called "whatever.html" it returns the / page from the default website in the config. Regards, Graham -- - [EMAIL PROTECTED] "There's a moon over Bourbon Street tonight..."
Re: mod_log_config
Yes please ! And if you could also add a nice feature to be able to switch logging on and off - that would be even nicer (i.e. rather than using clever !env= conditional logging - just be able to say that for this Vhost/Directory/File logging is 'off' (and not /dev/null or any hack)). Dw. On Sat, 24 Aug 2002, Ian Holsman wrote: > I want to change mod_log_config so that the open/writing of the logfile > can be overwritten by another module via optional functions. > > I think this would be handy for things log mod_log_spread and for people > who have to write audit trails into each log line. > > This would also have a added benefit of making buffered-logs a runtime > configurable option instead of a compile time one. > > the only reason I'm asking is to make sure that this wasn't discussed a > year ago and that there is a good reason not to go with a optional funciton. > > --Ian > >
Re: [PATCH] fixes segfault in mod_cache (2.0.40)
Apache behaviour with this patch (or without mod_cache):
The request:
GET https://whatever.html HTTP/1.0
is equivalent to:
GET / HTTP/1.0
I'm wondering whether this is the desired behaviour? This is
also the behaviour of a 1.3.x Apache. Maybe Apache should block
this kind of requests and return an error message??
Kris Verbeeck wrote:
>
> Hi,
>
> Someone in our QA team tried the following test:
>
> telnet 80
> GET https://whatever.html HTTP/1.0
>
> this resulted in a segfault for the child that handled the request.
> Agreed, this is not a normal HTTP request, but firing enough of them
> will surely DoS the server.
>
> Our apache runs on Sparc/Solaris8 and 'httpd -l' gives:
>
> Compiled in modules:
> core.c
> mod_access.c
> mod_cache.c
> mod_disk_cache.c
> mod_deflate.c
> mod_jk.c
> mod_log_config.c
> mod_env.c
> mod_setenvif.c
> mod_ssl.c
> prefork.c
> http_core.c
> mod_mime.c
> mod_alias.c
>
> Gdb told me that there was a null ppinter dereference in
> ap_cache_get_cache_type when it tried to compare the request's
> URL with the prefix from the configuration.
>
> The patch will just return NULL when the URL is NULL and results
> in no caching for that request (which seems reasonable since there
> ios no URL to cache).
>
> ps: I don't know whether the actual fix of this problem should
> be in cache_util.c or somewhere in the URI parsing routines.
>
> --
> ir. Kris Verbeeck
> Development Engineer
>
> Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
> T: +32 16 28 70 64
> F: +32 16 28 70 77
>
> Ubizen - We Secure e-business - www.ubizen.com
>
>
>
> --- httpd-2.0.40/modules/experimental/cache_util.c Sun Jun 23 08:10:00 2002
> +++ httpd-2.0.40-PATCHED/modules/experimental/cache_util.c Mon Aug 26 17:28:37
>2002
> @@ -104,6 +104,12 @@
> const char *type = NULL;
> int i;
>
> +/* we can't cache if there's no URL
> + * fixes segfault for 'GET https://whatever.html HTTP/1.0' request
> + * on HTTP port (e.g. 80)
> + */
> +if (!url) return NULL;
> +
> /* loop through all the cacheenable entries */
> for (i = 0; i < conf->cacheenable->nelts; i++) {
> struct cache_enable *ent =
--
ir. Kris Verbeeck
Development Engineer
Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
T: +32 16 28 70 64
F: +32 16 28 70 77
Ubizen - We Secure e-business - www.ubizen.com
