[STATUS] (httpd-2.1) Wed Jun 18 23:45:15 EDT 2003

[Rodent of Unusual Size]

APACHE 2.1 STATUS:  -*-text-*-
Last modified at [$Date: 2003/05/29 15:07:11 $]

Release [NOTE that only Alpha/Beta releases occur in 2.1 development]:

2.1.0   : in development

Please consult the following STATUS files for information
on related projects:

* srclib/apr/STATUS
* srclib/apr-util/STATUS
* docs/STATUS

Contributors looking for a mission:

* just do an egrep on "TODO" or "XXX" and see what's there


CURRENT RELEASE NOTES:


RELEASE SHOWSTOPPERS:


CURRENT VOTES:

* Promote mod_cache from experimental to non-experimental
  status (keep issues noted below in EXPERIMENTAL MODULES as
  items to be addressed as a supported module).
  +1: jim, bnicholes
  -0: jerenkrantz
  -1: stoddard
  There are a couple of problems that need to be resolved
  before this module is moved out of experimental. 
  1) We need to at least review and comment on the RFC violations
  2) Resolve issue of how to cache page fragements (or perhaps -if- we
  want to cache page fragements). Today, mod_cache/mod_mem_cache
  will cache #include 'virtual' requests (but not #include 'file' 
  requests). This was accomplished by making CACHE_IN a
  CONTENT_SET-1 filter to force it to run before the SUBREQ_CORE
  filter.  But now responses cannot be cached that include the
  effects of having been run through CONTENT_SET filters
  (mod_deflate, mod_expires, etc).  We could rerun all the
  CONTENT_SET filters on the cached response, but this will not
  work in all cases. For example, mod_expires relies on installing
  the EXPIRATION filter during fixups. Contents served out of
  mod_cache (out of the quick_handler) bypass -all- the request
  line server hooks (Ryan really hated this. It is great for
  performance, but bad because of the complications listed above).
 

  jerenkrantz: There are a slew of RFC compliance bugs filed in Bugzilla
   for mod_cache (see 'RFC 2616 violations' below).  I think
   fixing them is a pre-requisite before it isn't experimental.

* httpd-std.conf and friends

  a) httpd-std.conf should be tailored by install (from src or
 binbuild) even if user has existing httpd.conf
 +1:   trawick, slive, gregames, ianh, Ken, wrowe, jwoolley, jim, nd
   wrowe - prefer httpd.default.conf to avoid ambiguity with cvs

  b) tailored httpd-std.conf should be copied by install to
 sysconfdir/examples
 -0:   striker

  c) tailored httpd-std.conf should be installed to
 sysconfdir/examples or manualdir/exampleconf/
 +1:   slive, trawick, Ken, nd (prefer the latter)

  d) Installing a set of default config files when upgrading a server
 doesn't make ANY sense at all.
 +1:   ianh - medium/big sites don't use 'standard config' anyway, as it
  usually needs major customizations
 -1:   Ken, wrowe, jwoolley, jim, nd
   wrowe - diff is wonderful when comparing old/new default configs,
   even for customized sites that ianh mentions
   jim - ... assuming that the default configs have been updated
 with the required inline docs to explain the
 changes

* If the parent process dies, should the remaining child processes
  "gracefully" self-terminate. Or maybe we should make it a runtime
  option, or have a concept of 2 parent processes (one being a 
  "hot spare").
  See: Message-ID: <[EMAIL PROTECTED]>

  Self-destruct: Ken, Martin, Lars
  Not self-destruct: BrianP, Ian, Cliff, BillS
  Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd

  /* The below was a concept on *how* to handle the problem */
  Have 2 parents: +1: jim
  -1: Justin, wrowe, rederpj, nd
  +0: Lars, Martin (while standing by, could it do
something useful?)

* Make the worker MPM the default MPM for threaded Unix boxes.
  +1:   Justin, Ian, Cliff, BillS, striker, wrowe, nd
  +0:   BrianP, Aaron (mutex contention is looking better with the
latest code, let's continue tuning and testing), rederpj, jim
  -0:   Lars

RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:

* Filter stacks and subrequests, redirects and fast redirects.
  There's at least one PR that suffers from the current unclean behaviour
  (which lets the server send garbage): PR 17629
  nd says: Every subrequest should get its own filter stack with the
   subreq_core filter as bottom-most. That filter does two things:
 - swallow EOS buckets
 - redirect the data stream to the upper request's (rr->main)
   filter chain directly after the subrequest's starting
   

[STATUS] (httpd-2.0) Wed Jun 18 23:45:12 EDT 2003

[Rodent of Unusual Size]

APACHE 2.0 STATUS:  -*-text-*-
Last modified at [$Date: 2003/06/17 15:20:02 $]

Release:

2.0.47  : in development
2.0.46  : released May 28, 2003 as GA.
2.0.45  : released April 1, 2003 as GA.
2.0.44  : released January 20, 2003 as GA.
2.0.43  : released October 3, 2002 as GA.
2.0.42  : released September 24, 2002 as GA.
2.0.41  : rolled September 16, 2002.  not released.
2.0.40  : released August 9, 2002 as GA.
2.0.39  : released June 17, 2002 as GA.
2.0.38  : rolled June 16, 2002.  not released.
2.0.37  : rolled June 11, 2002.  not released.
2.0.36  : released May 6, 2002 as GA.
2.0.35  : released April 5, 2002 as GA.
2.0.34  : tagged March 26, 2002.
2.0.33  : tagged March 6, 2002.  not released.
2.0.32  : released Feburary 16, 2002 as beta.
2.0.31  : rolled Feburary 1, 2002.  not released.
2.0.30  : tagged January 8, 2002.  not rolled.
2.0.29  : tagged November 27, 2001.  not rolled.
2.0.28  : released November 13, 2001 as beta.
2.0.27  : rolled November 6, 2001
2.0.26  : tagged October 16, 2001.  not rolled.
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

Contributors looking for a mission:

* just do an egrep on "TODO", "XXX" and see what's there

RELEASE SHOWSTOPPERS:

PATCHES TO PORT FROM 2.1
  [ please place file names and revisions from HEAD here, so it is easy to
identify exactly what the proposed changes are! ]

* core_output_filter: don't split the brigade after a FLUSH bucket
  if it's the last bucket.  This prevents creating unneccessary empty
  brigades which may not be destroyed until the end of a keepalive
  connection.
  http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/core.c.diff?r1=1.237&r2=1.238
  +1: brianp

* Win32: Whack the fully qualified names that appear in the log when
  loglevel debug is being used.
  http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/log.c.diff?r1=1.133&r2=1.134
  +1: stoddard

* Backport LimitInteralRecursion to 2.0 and 1.3.
  (1.3 patch is here: )
  (2.0 patch is here: )
  PR 19753.
  include/http_core.h r1.75, r1.76
  modules/http/http_request.c r1.156, r1.158
  server/core.c r1.236, r1.237
  server/request.c r1.126, r1.127
  +1: nd

* Replace some of the mutex locking in the worker MPM with
  atomic operations for higher concurrency.
  server/mpm/worker/fdqueue.c 1.24, 1.25
  +1: brianp
  -0: trawick  These gcc warnings seem to point out uncleanness
   that should be resolved first.  Perhaps "volatile"-ity
   is inconsistent?  (gcc 3.2 on UL 1.0)
  fdqueue.c: In function `queue_info_cleanup':
  fdqueue.c:89: warning: passing arg 1 of `apr_atomic_casptr' from
incompatible pointer type
  fdqueue.c: In function `ap_queue_info_set_idle':
  fdqueue.c:142: warning: passing arg 1 of `apr_atomic_casptr' from
 incompatible pointer type
  fdqueue.c: In function `ap_queue_info_wait_for_idler':
  fdqueue.c:232: warning: passing arg 1 of `apr_atomic_casptr' from
 incompatible pointer type

* Rewrite how proxy sends its request to allow input bodies to 
  morph the request bodies.  Previously, if an input filter
  changed the request body, the original C-L would be sent which
  would be incorrect.

  Due to HTTP compliance, we must either send the body T-E: chunked
  or include a C-L for the request body.  Connection: Close is not
  an option. [jerenkrantz2002/12/08 21:37:27]
  +1: stoddard, striker, jim
  -1: brianp (we need a more robust solution than what's in 2.1 right now),
  jerenkrantz (should be fixed, but I don't have time to do this)

* Extend the SetEnvIf directive to capture subexpressions of the
  matched value. This is related to the backport proposal below ... ;-)
  

[STATUS] (apache-1.3) Wed Jun 18 23:45:07 EDT 2003

[Rodent of Unusual Size]

APACHE 1.3 STATUS:  -*-text-*-
  Last modified at [$Date: 2003/06/02 13:13:45 $]

Release:

   1.3.28-dev: In development. Jim proposes a release mid-June
   and offers to be RM.
   1.3.27: Tagged September 30, 2002. Announced Oct 3, 2002.
   1.3.26: Tagged June 18, 2002.
   1.3.25: Tagged June 17, 2002. Not released.
   1.3.24: Tagged Mar 21, 2002. Announced Mar 22, 2002.
   1.3.23: Tagged Jan 21, 2002.
   1.3.22: Tagged Oct 8, 2001.  Announced Oct 12, 2001.
   1.3.21: Not released.
 (Pulled for htdocs/manual config mismatch. t/r Oct 5, 2001)
   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: Tagged and rolled 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, 1999. Released and announced on 19th.
1.3.8: Not released.
1.3.7: Not released.
1.3.6: Tagged and rolled on Mar. 22, 1999. Released and announced on 24th.
1.3.5: Not released.
1.3.4: Tagged and rolled on Jan. 9, 1999.  Released on 11th, announced on 12th.
1.3.3: Tagged and rolled on Oct. 7, 1998.  Released on 9th, announced on 10th.
1.3.2: Tagged and rolled on Sep. 21, 1998. Announced and released on 23rd.
1.3.1: Tagged and rolled on July 19, 1998. Announced and released.
1.3.0: Tagged and rolled on June 1, 1998.  Announced and released on the 6th.
   
2.0  : Available for general use, see httpd-2.0 repository

RELEASE SHOWSTOPPERS:

RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:

   * Current vote on 3 PRs for inclusion:
  Bugz #17877 (passing chunked encoding thru proxy)
+1: jim, chuck, minfrin
  Bugz #9181 (Unable to set headers on non-2XX responses)
+1: Martin, Jim
  Gnats #10246 (Add ProxyConnAllow directive)
+0: Martin (or rather -.5, see dev@ Message
<[EMAIL PROTECTED]>)

* 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.  (Will asks 'wasn't this patched?')

* 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:


Available Patches (Most likely, will be ported to 2.0 as appropriate):

   *  A rewrite of ap_unparse_uri_components() by Jeffrey W. Baker
 <[EMAIL PROTECTED]> to more fully close some segfault potential.
Message-ID: <[EMAIL PROTECTED]>
Status:  Jim +1 (for 1.3.19), Martin +0

* 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 bugfix to mod_autoindex
  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: Martin +1(untested), Ken +1(untested)
   
* Salvador Ortiz Garcia <[EMAIL PROTECTED]>' patch to allow Directory

Little question on apache internals

[Sebastian Abt]

Hi all,

I'm currently writing an Apache module (Apache 1.3.27) for virtual
masshosting based on a SQL backend (currently MySQL later on
PostgreSQL).  Therefore I'm searching for information about the
differences between requests (request_rec) and servers (server_rec).

Can anybody tell me the lifetime of a request or a server record?
As far as I understand the used terminology, a request record handles
all requests made by a user when navigating to a specific URL.

If that's right it would mean that all calls made to my translate-
handler for such a session access the same pool inside the request
record but if I navigate to another domain on the same server it would
be a different request with its own new pool, wouldn't it?

I need this information for implementing some kind of caching. I really
don't want to query my database for each "stupid" file or image the user
requests.

It would be very nice if you could explain me the difference or if
someone could give me a link to a more detailed documentation.

Thanks in advance,
best regards

sebastian

RE: [PATCH] EventLog display name patch

[William A. Rowe, Jr.]

At 03:04 PM 6/18/2003, Juan Rivera wrote:

>Is there any other way to get the display name? I look for other ways but couldn't 
>figure out another approach. 

 From the registry.  It just looks like we look up the display name a little
too late for some classes of errors.  

Working on this.

Bill

RE: [PATCH] EventLog display name patch

[Juan Rivera]

Title: RE: [PATCH] EventLog display name patch





Is there any other way to get the display name? I look for other ways but couldn't figure out another approach.


Juan


-Original Message-
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, June 18, 2003 3:43 PM
To: [EMAIL PROTECTED]
Subject: Re: [PATCH] EventLog display name patch


At 09:59 AM 6/18/2003, Juan Rivera wrote:


>The current nt_eventlog implementation has the hardcoded "Apache Service" as the event log application name. This can be problematic if you have multiple instances of Apache running on the same box.

>
>To fix this, I made midifications on two files: 
>
>The service.c.patch simply adds the display name used during -k install into the actual service command line. 


This part of the patch isn't acceptable because;


>The service command like would be: 
>
>Apache2.exe -k runservice -n "web server 1" 


this requirement above breaks exiting installed services, which is not good,
IMHO.


>This is important because the display_name variable will set when the service is executed. This variable is used by the nt_eventlog.c

I believe we can go a little further to assure that is filled in or retrieved as soon
as it is needed.  Let me look for the underlying bug.


>The nt_eventlog.c patch replaces the hard-coded registry path SYSTEM\\CurrentControlSet\\Services\\EventLog\\Application\\Apache Service

>
>with 
>
>SYSTEM\\CurrentControlSet\\Services\\EventLog\\Application\\ + display_name 
>
>Now your messages will be loged with the right application name. So you can identify which service actually generated the error.

You must also register the event provider, which I will verify in your patch
or code up if it's missing before I commit.


I was originally hesitant to waste the additional space to create event loggers
for each copy of Apache.  You've sold me, and I understand your concern
about trying to review an event log of many active instances of Apache.


Most of my httpd time has been stuck in ssl issues, I hope now to dig out
and get back to your patch and port the Win98/ME support from 1.3 as well.


Thanks for all of your efforts, Juan!


Bill

Re: [PATCH] mod_dav streamy error handling

[Ben Collins-Sussman]

[Reposting patch, with gstein's added check for r->sent_bodyct.]

Have mod_dav deal with errors that happen during a streamy provider response.

* mod_dav.c (dav_method_propfind, dav_method_report): if the dav
  provider throws an error in the middle of streaming a response, have
  mod_dav log an error and abort the connection.



Index: modules/dav/main/mod_dav.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/dav/main/mod_dav.c,v
retrieving revision 1.94
diff -u -r1.94 mod_dav.c
--- modules/dav/main/mod_dav.c  3 Jun 2003 22:09:24 -   1.94
+++ modules/dav/main/mod_dav.c  18 Jun 2003 19:47:44 -
@@ -2059,8 +2059,18 @@
 }
 
 if (err != NULL) {
-/* ### add a higher-level description? */
-return dav_handle_err(r, err, NULL);
+/* If an error occurred during the resource walk, there's
+   basically nothing we can do but abort the connection and
+   log an error.  This is one of the limitations of HTTP; it
+   needs to "know" the entire status of the response before
+   generating it, which is just impossible in these streamy
+   response situations. */
+err = dav_push_error(r->pool, err->status, 0,
+ "Provider encountered an error while streaming"
+ " a multistatus PROPFIND response.", err);
+dav_log_err(r, err, APLOG_ERR);
+r->connection->aborted = 1;
+return DONE;
 }
 
 /* Finish up the multistatus response. */
@@ -4033,9 +4043,22 @@
 /* run report hook */
 if ((err = (*vsn_hooks->deliver_report)(r, resource, doc,
 r->output_filters)) != NULL) {
-/* NOTE: we're assuming that the provider has not generated any
-   content yet! */
-return dav_handle_err(r, err, NULL);
+if (! r->sent_bodyct)
+  /* No data has been sent to client yet;  throw normal error. */
+  return dav_handle_err(r, err, NULL);
+
+/* If an error occurred during the report delivery, there's
+   basically nothing we can do but abort the connection and
+   log an error.  This is one of the limitations of HTTP; it
+   needs to "know" the entire status of the response before
+   generating it, which is just impossible in these streamy
+   response situations. */
+err = dav_push_error(r->pool, err->status, 0,
+ "Provider encountered an error while streaming"
+ " a REPORT response.", err);
+dav_log_err(r, err, APLOG_ERR);
+r->connection->aborted = 1;
+return DONE;
 }
 
 return DONE;

Re: [PATCH] EventLog display name patch

[William A. Rowe, Jr.]

At 09:59 AM 6/18/2003, Juan Rivera wrote:

>The current nt_eventlog implementation has the hardcoded "Apache Service" as the 
>event log application name. This can be problematic if you have multiple instances of 
>Apache running on the same box.
>
>To fix this, I made midifications on two files: 
>
>The service.c.patch simply adds the display name used during -k install into the 
>actual service command line. 

This part of the patch isn't acceptable because;

>The service command like would be: 
>
>Apache2.exe -k runservice -n "web server 1" 

this requirement above breaks exiting installed services, which is not good,
IMHO.

>This is important because the display_name variable will set when the service is 
>executed. This variable is used by the nt_eventlog.c

I believe we can go a little further to assure that is filled in or retrieved as soon
as it is needed.  Let me look for the underlying bug.

>The nt_eventlog.c patch replaces the hard-coded registry path 
>SYSTEM\\CurrentControlSet\\Services\\EventLog\\Application\\Apache Service
>
>with 
>
>SYSTEM\\CurrentControlSet\\Services\\EventLog\\Application\\ + display_name 
>
>Now your messages will be loged with the right application name. So you can identify 
>which service actually generated the error.

You must also register the event provider, which I will verify in your patch
or code up if it's missing before I commit.

I was originally hesitant to waste the additional space to create event loggers
for each copy of Apache.  You've sold me, and I understand your concern
about trying to review an event log of many active instances of Apache.

Most of my httpd time has been stuck in ssl issues, I hope now to dig out
and get back to your patch and port the Win98/ME support from 1.3 as well.

Thanks for all of your efforts, Juan!

Bill

Re: OpenSSL locking was Re: mod_ssl broken as DSO in HEAD

[Geoff Thorpe]

Hi,

On June 18, 2003 02:28 am, Justin Erenkrantz wrote:
> Finally got a chance to dig some more and found that if I add:
>
> CRYPTO_set_id_callback(openssl_id);
>
> to ssl_hook_pre_config before the ENGINE_load_builtin_engines and where
> openssl_id is defined as:
>
> static unsigned long openssl_id(void)
> {
> /* FIXME: This is lame and not portable. -aaron */
> return (unsigned long) apr_os_thread_current();
> }
>
> (The above is used in flood - hence Aaron's comment.)
>
> The SEGVs go away if we do this.  Does this make sense given the
> internals of OpenSSL?

I'm not the best person to talk about with respect to locking in openssl 
(I more or less detest threads, an Alan Cox quote about state-machines 
springs to mind...). That said, :-), I took another look at the backtrace 
you posted and it certainly seems odd. Digging ... the implementation of 
CRYPTO_thread_id() is;

unsigned long CRYPTO_thread_id(void)
{
unsigned long ret=0;

if (id_callback == NULL)
{
#ifdef OPENSSL_SYS_WIN16
ret=(unsigned long)GetCurrentTask();
#elif defined(OPENSSL_SYS_WIN32)
ret=(unsigned long)GetCurrentThreadId();
#elif defined(GETPID_IS_MEANINGLESS)
ret=1L;
#else
ret=(unsigned long)getpid();
#endif
}
else
ret=id_callback();
return(ret);
}

The segfault is (or appears to be, stack smashing possibilities aside) 
occuring in a function called from this, and the address is less than the 
other openssl library functions in the trace, but not by much. Which begs 
the question - is id_callback set to something (and if so, what?) or does 
the address correspond to getpid()? Unfortunately, I think the easiest 
way to see this would be to hack the above function (and perhaps others 
in crypto/cryptlib.c that deal with id_callback) to watch what is going 
on.

> On this same tangent, do we need to be doing all of the CRYPTO_
> stuff? I don't believe we are doing that.  And, I know in flood, we had
> lots of problems until we called them.  So, I think mod_ssl should be
> passing the lock structures - especially for worker MPM builds...

Whenever I build Apache, I typically build a version of openssl configured 
with "no-threads" so this sort of issue is implicitly ruled out. It also 
removes a few meaningless function calls given that (multi-forked, 
traditional) Apache doesn't need any thread-safe locking. However I know 
that isn't the answer to your question in general, as many people will be 
using the openssl libs bundled with their system and/or trying to use 
Apache2 in a threaded setup.

> While I've got someone's attention, I have some real issues in that
> both of the OpenSSL lock implementations (CRYPTO_set_locking_callback
> and CRYPTO_set_dynlock_*) require global variables to implement.  I
> don't think I can say 'ick' loud enough.
>
> What would the possibility/feasibility of passing application-specific
> opaque values through the CRYPTO_lock callbacks?  Say
>
> static void openssl_lock(int mode, int n, void *app, const char *file,
> int line)
>
> static CRYPTO_dynlock_value *ssl_dyn_create(void *app, const char*
> file, int line)
>
> We can have app passed into the CRYPTO_set functions - in the case of
> httpd, it would be the pools for ssl_dyn_create *or* the global array
> of locks that openssl_lock would require.  You don't know how much
> happier that would make me if we could do that.  globals are just so
> icky.  -- justin

For this and the previous question, the short answer is "maybe, but it 
doesn't solve the problem of working with existing versions".

In both cases, ie. the segfault you're seeing *and* the issue about 
attaching an opaque pointer to caller-provide locking callbacks, it would 
make sense to take that conversation over to openssl-dev. In particular, 
we should get any appropriate details into the request-tracking system. 
BTW: Once we're over there, Richard Levitte may be able to provide better 
comments than I on this locking stuff, particularly as the dynlock stuff 
was (IIRC) his creation.

Cheers,
Geoff

-- 
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/

RE: OpenSSL locking was Re: mod_ssl broken as DSO in HEAD

[MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)]

-Original Message-
>From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]
>[SNIP]
>
>On this same tangent, do we need to be doing all of the CRYPTO_
stuff? 
>I don't believe we are doing that.  And, I know in flood, we had lots of 
>problems until we called them.  So, I think mod_ssl should be passing the
lock 
>structures - especially for worker MPM builds...


Hmmn.. I have a vague recollection of posting a patch do to exactly that..
and it was rejected because of some reason.
I already have a patch which does that if ppl. are interested in evaluating
it. (Off to dig my mails to find what happened.)

-Madhu

RE: [PATCH] EventLog display name patch

[Juan Rivera]

Title: [PATCH] EventLog display name patch









BTW, the service.c
patch should also take care of the following bug. If your configuration file
has a syntax error, you will get something like this in your event log:

 

The
Apache service named  reported the
following error:

>>> Syntax error on line 32 of C:/Apache2/conf/httpd.conf:

 

What is missing is the actual service
display name between the words named and reported. With the service.c
patch it will show it like this:

 

The
Apache service named My Service Name reported the following error:

>>> Syntax error on line 32 of C:/Apache2/conf/httpd.conf:

 

 

-Original Message-
From: Juan Rivera
[mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 18, 2003
10:59 AM
To: [EMAIL PROTECTED]
Subject: [PATCH] EventLog display
name patch

 

 

The current nt_eventlog implementation has the
hardcoded "Apache Service" as the event log application name. This
can be problematic if you have multiple instances of Apache running on the same
box.

If, for instance, you register multiple apache
services using different display names (-k install -n "My display
name"), it is necessary that the events in the event log map to the actual
service that generated it, not "Apache Service".

To fix this, I made midifications on two files:


The service.c.patch simply adds the display name used
during -k install into the actual service command line. 

For example if you run 

Apache2.exe -k install -n "web server 1"


The service command like would be: 

Apache2.exe -k runservice -n "web server 1"


Instead of 

Apache2.exe -k runservice 

This is important because the display_name variable
will set when the service is executed. This variable is used by the
nt_eventlog.c

The nt_eventlog.c patch replaces the hard-coded
registry path SYSTEM\\CurrentControlSet\\Services\\EventLog\\Application\\Apache
Service

with 

SYSTEM\\CurrentControlSet\\Services\\EventLog\\Application\\
+ display_name 

Now your messages will be loged with the right
application name. So you can identify which service actually generated the
error.

Juan 

  

[PATCH] EventLog display name patch

[Juan Rivera]

Title: [PATCH] EventLog display name patch






The current nt_eventlog implementation has the hardcoded "Apache Service" as the event log application name. This can be problematic if you have multiple instances of Apache running on the same box.

If, for instance, you register multiple apache services using different display names (-k install -n "My display name"), it is necessary that the events in the event log map to the actual service that generated it, not "Apache Service".

To fix this, I made midifications on two files:


The service.c.patch simply adds the display name used during -k install into the actual service command line.


For example if you run


Apache2.exe -k install -n "web server 1"


The service command like would be:


Apache2.exe -k runservice -n "web server 1"


Instead of


Apache2.exe -k runservice


This is important because the display_name variable will set when the service is executed. This variable is used by the nt_eventlog.c

The nt_eventlog.c patch replaces the hard-coded registry path SYSTEM\\CurrentControlSet\\Services\\EventLog\\Application\\Apache Service

with


SYSTEM\\CurrentControlSet\\Services\\EventLog\\Application\\ + display_name


Now your messages will be loged with the right application name. So you can identify which service actually generated the error.

Juan


 




service.c.path
Description: Binary data


nt_eventlog.c.patch
Description: Binary data

Re: ap_get_module_config

[Jeff Trawick]

Rahul Kohli wrote:
Does the Apache 1.x method "ap_get_module_config" exist for Apache 2 also.
grep for it in Apache's include directory...  (you'll find it)

Where can I find the info. on various Apache 1.x routines counterpart for Apache 2.x.
fairly simple renames of 1.3 functions show up in ap_compat.h, 
apu_compat.h, apr_compat.h

Re: [RELEASE CANDIDATE] Apache::Test 1.03-dev

[Sergey V. Stashinskas]

Hi,

5.0-RELEASE FreeBSD, apache 1.3.27, mod_perl 1.27, perl 5.8.0

All tests successful.


-Original Message-
From: Stas Bekman <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED],httpd-test-dev list <[EMAIL PROTECTED]>
Date: Wed, 18 Jun 2003 19:13:46 +1000
Subject: [RELEASE CANDIDATE] Apache::Test 1.03-dev

> 
> I've uploaded 1.03's release candidate. If nobody finds any faults, I'll 
> upload it tomorrow on CPAN. (libapreq needs to rely on 1.03 fixes to release 
> its 1.2's version).
> 
> Please try it out:
> http://www.apache.org/~stas/Apache-Test-1.03-dev.tar.gz
> 
> Test it with mod_perl 1.0:
> 
> perl Makefile.PL -httpd /path/to/1.x/httpd && make test
> 
> and with mod_perl 2.0:
> 
> perl Makefile.PL -httpd /path/to/2.x/httpd && make test
> 
> Alternatively you can do:
> 
> APACHE=/path/to/1.x/httpd perl Makefile.PL && make test
> 
> or for C-style shell users:
> 
> env APACHE=/path/to/1.x/httpd perl Makefile.PL && make test
> 
> __
> 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: mod_ssl broken as DSO in HEAD

[Geoff Thorpe]

Hi there,

On June 16, 2003 10:14 pm, William A. Rowe, Jr. wrote:
> At 08:13 PM 6/16/2003, Justin Erenkrantz wrote:
> >The change to move OpenSSL's initialization to ssl_hook_pre_config is
> > busted when mod_ssl is a DSO.  It will try to call all of the OpenSSL
> > init sequences twice which I don't believe OpenSSL supports.
>
> We may need to register proper 'cleanups' to 'unload' all of the
> engines, as you point out in this problem;

If things really are supposed to initialise (and unload) two times on 
startup, then I guess this is what you should do for openssl too.

> Right.  What is more interesting (as a DSO) is that our module, and
> ergo the SSL library, should have been unloaded and reinitialized. 
> Apparently we can't count on that behavior, though.

Depending on what gets initialised, there are a variety of things you 
might need to unload from openssl's point of view. However, this is 
usually an issue for people from a memory leak point of view, not a 
double initialisation. Potential issue: in a few places, openssl uses a 
global "is_set" variable to handle first-time initialisation of callbacks 
(eg. malloc). The idea is that once they're set, they can't be overriden. 
If you don't need to do *that* twice on startup, there's no problem. If 
you do, then it shouldn't matter *provided* you can live without error 
checking - if it fails then the (correct) global is still set from the 
previous initialisation, and if it succeeds then the globals needed 
setting anyway. Of course if it fails on the first initialisation then 
you have a bug that you'll never spot ... BTW: this is only for stuff 
where you are providing callback overrides for memory management, thread 
locking, error stacks, etc.

> Well, if it isn't done before pre-config, the entire ENGINE support
> code in the command handler for SSLCryptoDevice is borked.  I know, I
> already spent two days there.

 SSLCryptoDevice ... I don't like the sound of that ;-)

> If we force the SSL Library to stay loaded (reliably, across platforms)
> between startup phases (with the SSL module itself unloading and
> reloading - ick), then saving the initialization in pprocess might be a
> viable alternative, but where?  register_hooks is no better than
> pre_config in this regard.
>
> Or we simply work out an ENGINE_unload_engines() as a cleanup.  But of
> course, OpenSSL doesn't really like to be cleared and restarted from
> scratch, so I don't know if this is really trivial or a nightmare.

This can be done easily enough, it's just a case of knowing what bits you 
need to clean up. What is beyond my reach however is a way of convincing 
Apache to run in one process and start up and close down cleanly - this 
is normally the easiest way to check for missing cleanups because they 
show up as leaks. I could otherwise give you some tips on cleanup 
sequences, but without a way of checking the cleanup code for leaks we'd 
be acting on faith that the sequence is (a) complete, and (b) the minimum 
necessary (no point putting redundant calls in and risking extra static 
linking).

Let me know if, and how, I can help. If you want to hunt around yourself, 
check out the "apps_startup()" and "apps_shutdown()" macro definitions 
inside apps/apps.h in the openssl source. You may not need all of those 
cleanups, and of course YMMV :-)

Cheers,
Geoff

-- 
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/

ap_get_module_config

[Rahul Kohli]

Does the Apache 1.x method "ap_get_module_config" exist for Apache 2 also. If no what 
is the counterpart for this on Apache 2.x

Where can I find the info. on various Apache 1.x routines counterpart for Apache 2.x.

Thanks,
> Rahul Kohli

Re: [PATCH] mod_dav streamy error handling

[Justin Erenkrantz]

--On Wednesday, June 18, 2003 12:47 AM -0700 Greg Stein <[EMAIL PROTECTED]> 
wrote:

I think dropping the connection on the client rather than sending a bogus
body is probably "better". Neither solution is great, but I'll take a drop
and a truncated response over a bad body.
Sure, I can live with that.  +1.

The server error logs should have the error details anyway.  -- justin

Re: [PATCH] mod_dav streamy error handling

[Greg Stein]

On Wed, Jun 18, 2003 at 12:03:50AM -0700, Justin Erenkrantz wrote:
> --On Tuesday, June 17, 2003 11:49 PM -0700 Greg Stein <[EMAIL PROTECTED]> 
> wrote:
> 
> >Definitely possible. But we have no better measure to detect that some
> >output has been generated. Once *some* output has been started (and, say, 
> >it
> >has been buffered by some filter), then the only likely error that would
> >come back from deliver_report is some kind of 5xx error. i.e. bad juju. In 
> >a
> >properly functioning server, that should never happen, so the exposure to
> >this kind of failure mode is very limited.
> 
> How bad would it be if we incorrectly think that no body has been sent when 
> one has been pushed into the chain?  Is it just going to be a 207 with a 
> corrupted XML response - the error body would be appended to whatever has 
> already been sent?

Yes. That is the behavior today. Ben is trying to clean that up. The
proposed patch reduces the chance of these mixed response/error bodies.

> If we guess right (that there has been a body), then 
> it'd be a 207 with the first portion and then a closed connection.  So, 
> either case, the client is just hosed.

Yup.

> Perhaps it makes sense to always emit the error 'body' to the client, then 
> abort the connection.  That way, there is some hint that something is 
> majorly wrong in the server by looking at the content.  Not entirely sure.  

I think dropping the connection on the client rather than sending a bogus
body is probably "better". Neither solution is great, but I'll take a drop
and a truncated response over a bad body.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: [PATCH] mod_dav streamy error handling

[Justin Erenkrantz]

--On Tuesday, June 17, 2003 11:49 PM -0700 Greg Stein <[EMAIL PROTECTED]> wrote:

Definitely possible. But we have no better measure to detect that some
output has been generated. Once *some* output has been started (and, say, it
has been buffered by some filter), then the only likely error that would
come back from deliver_report is some kind of 5xx error. i.e. bad juju. In a
properly functioning server, that should never happen, so the exposure to
this kind of failure mode is very limited.
How bad would it be if we incorrectly think that no body has been sent when 
one has been pushed into the chain?  Is it just going to be a 207 with a 
corrupted XML response - the error body would be appended to whatever has 
already been sent?  If we guess right (that there has been a body), then it'd 
be a 207 with the first portion and then a closed connection.  So, either 
case, the client is just hosed.

Perhaps it makes sense to always emit the error 'body' to the client, then 
abort the connection.  That way, there is some hint that something is majorly 
wrong in the server by looking at the content.  Not entirely sure.  -- justin