Re: CGI bucket needed

[Brian Pane]

On Tue, 2002-09-24 at 21:43, William A. Rowe, Jr. wrote:

> The thought is, if we call pass_brigade or read_brigade in a 
> non-blocking mode, and nothing can be processed, we get back
> a bucket containing a pollset of some sort (either multiple handles
> assembled by all the intervening filters, or multiple pollfd items
> each in their own bucket, each appended by the read.)
> 
> It would then be possible to assemble a pollset for CGI processing,
> dealing with all of the intervening filters.

Where would you poll the pollset?  If the poll is in the
handler, there's still a risk of deadlock when the handler
passes data to the output filter stack (specifically, there's
a risk of deadlock in the C-L filter).  But if the poll is
in the filters, it will be difficult to get the right code
invoked when a pollfd is signaled (because the necessary
code might be in a completely different filter).

Brian

Re: cvs commit: apache-1.3/src/modules/standard mod_headers.c

[William A. Rowe, Jr.]

Why did you principally credit Sander van Zoest for submitting the
patch of Michael Radwin  ?

Bill
  

At 06:22 PM 9/25/2002, [EMAIL PROTECTED] wrote:
>dirkx   2002/09/25 16:22:34
>
>  Modified:src  CHANGES
>   src/modules/standard mod_headers.c
>  Log:
>  Scratch another its - this patchs allows me to hugely simply auth modules
>  which use non 4xx methods for auth (such as cookies, referers ,etc).
>  
>  Submitted by Sander van Zoest (for a slightly different reason) - see
>  explanation below.
>  
>  From: Sander van Zoest
>  To: [EMAIL PROTECTED]
>  
>  It is common practice to set Cookie's to pass along on HTTP
>  redirects for "login" authentication.
>  
>  When implementing P3P  using
>  mod_headers.c the Header directive only sets r->headers_out
>  and does not pass the headers along for non-2XX responses
>  such as error pages and redirects.
>  
>  To provide this functionality we added the ErrorHeader
>  directive which populates r->err_headers_out instead.
>  
>  Below follows a patch for 1.3.X by Michael Radwin .
>  
>  I have some code that attempts to add Directive to 2.0.X, but
>  it seems that output_filters are shortcuted on 3XX responses.
>  While now by setting the Header directive it also passes the headers
>  along at for all non-2XX responses except 3XX responses.
>  
>  Cheers,
>  
>  --
>  Sander van Zoest
>  

Re: [PATCH] Alerting when fnctl is going bad

[Sander van Zoest]

On Wed, 25 Sep 2002, Justin Erenkrantz wrote:

> On Thu, Sep 26, 2002 at 02:11:59AM +0200, Dirk-Willem van Gulik wrote:
> > ->  Makes the wait loop no longer endless - but causes it
> > to bail out (and emit some warnings ahead of time) after
> > a couple of thousand consequituve EINTRs.
> Placing a 'magic number' on how many EINTRs is 'failure' doesn't
> seem right.  -- justin

Although, things like these have been done many times in the past.
Especially in BSD.  As long as the number is high enough to where
there doesn't seem to be an obvious reason to go above that, then
I do not see why not.

As for example, the limit of 7 dereferences on a symlink to prevent
symlink infinite loops.

--
Sander van Zoest  [EMAIL PROTECTED]
San Diego, CA, US http://Sander.vanZoest.com/

[STATUS] (httpd-2.0) Wed Sep 25 23:45:11 EDT 2002

[Rodent of Unusual Size]

APACHE 2.0 STATUS:  -*-text-*-
Last modified at [$Date: 2002/09/24 23:23:02 $]

Release:

2.0.43  : in development.
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


CURRENT RELEASE NOTES:


RELEASE SHOWSTOPPERS:


CURRENT VOTES:

* 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

  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

  d) Installing a set of default config files when upgrading a server
 doesn't make ANY sense at all.
 +1:   rbb, striker
   ianh - medium/big sites don't use 'standard config' anyway, as it
  usually needs major customizations
 -1:   Ken

* Should we always build [support*] binaries statically unless otherwise
  indicated?
Message-ID: <[EMAIL PROTECTED]>

  +1:  Ken, *wrowe [they are PITAs on OSX]
  -1:  Justin, Ian

* 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
  Not self-destruct: BrianP, Ian, Cliff, BillS
  Make it runtime configurable: Aaron, Jim, Justin
  Have 2 parents: +1: Jim
  -1: Justin, wrowe [for 2.0]
  +0: 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
  +0:   BrianP, Aaron (mutex contention is looking better with the
latest code, let's continue tuning and testing)
  -0:   Lars

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

* All handlers should always send content down even if r->header_only
  is set.  If not, it means that the HEAD requests don't generate the
  same headers as a GET which is wrong.
  Is this a showstopper?
+1: Justin, Ken
-1: Aaron

* server pushed CGI's not working.  (Is this a showstopper??)
  PR: 8482
  Message-ID: <[EMAIL PROTECTED]>

* HP/UX 10.20: compile breakage in APR.  Looks like it should be easy
  to fix, probably just some extraneous #include's that are fouling
  things up.
  PR: 9457
  Jeff: See my reply and patch in the PR (and previous commit to
  stop using "pipe" as a field name).  If patch is committed, we
  should be okay.  I'll wait to see if the user tests the patch.
  Update by Jeff 20020722: I got an account on HP 10.20.  It looks
  like some of the APR thread detection is screwed up.  If we find
  pthread.h but we can't compile the pthread test program we still
  think we can use threads.  For that reason, the patch I posted
  to the PR won't work as-is since a failed com

[STATUS] (apache-1.3) Wed Sep 25 23:45:06 EDT 2002

[Rodent of Unusual Size]

APACHE 1.3 STATUS:  -*-text-*-
  Last modified at [$Date: 2002/09/18 15:36:26 $]

Release:

   1.3.27-dev: In development. Jim proposes a t/r on or around
   Sept 24.
   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. Released and announced on 19th.
1.3.8: Not released.
1.3.7: Not released.
1.3.6: Tagged and rolled on Mar. 22. Released and announced on 24th.
1.3.5: Not released.
1.3.4: Tagged and rolled on Jan. 9.  Released on 11th, announced on 12th.
1.3.3: Tagged and rolled on Oct. 7.  Released on 9th, announced on 10th.
1.3.2: Tagged and rolled on Sep. 21. Announced and released on 23rd.
1.3.1: Tagged and rolled on July 19. Announced and released.
1.3.0: Tagged and rolled on June 1.  Announced and released on the 6th.
   
2.0  : Available for general use, see httpd-2.0 repository

RELEASE SHOWSTOPPERS:

   * Current vote on 2 PRs for inclusion:
  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]>)

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

* htpasswd.c and htdigest.c use tmpnam()... consider using
  mkstemp() when available.
Message-ID: <[EMAIL PROTECTED]>
Status:

* Dean's "unescaping hell" (unescaping the various URI components
  at the right time and place, esp. unescaping the host name).
Message-ID: <[EMAIL PROTECTED]>
Status:

* Martin observed a core dump because a ipaddr_chain struct contains
  a NULL-"server" pointer when being dereferenced by invoking "httpd -S".
Message-ID: <[EMAIL PROTECTED]>
Status: Workaround enabled. Clean solution can come after 1.3.19

* long pathnames with many components and no AllowOverride None
  Workaround is to define  with AllowOverride None,
  which is something all sites should do in any case.
Status: Marc was looking at it.  (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):

   * Backport of 2.0 ForceLanguagePriority directive
   /dist/httpd/contrib/patches/1.3/force_language_priority.patch
   Message-ID: <[EMAIL PROTECTED]>
   Status:

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

* 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 DirectoryIndex
  to refer to URIs for non-static 

Re: PKCS Mime Types

[Ian Holsman]

Rick Beton wrote:
> Hi Guys n Gals,
> 
> I'm new to this list. Forgive me therefore if I seem to barge in! :-)
> 
> I was wondering about the mime.types configuration file. There are what 
> appear to me to be a couple of omissions thus:
> 
> application/x-pkcs7-certificates p7b
> application/x-x509-email-certpem, cer
> 
> 
> because these extensions and Mime Types do seem to be in use. Microsoft 
> for example, use the .cer extension.
> 
hi Rick
The only extensions which can go in the mime.types are IANA sanctioned ones.

sorry ;(
> Regards,
> Rick
> 
> 
> 

Re: [PATCH] add simple ${ENV} substitution during config file read

[David Burry]

This may be confusing because people may begin to expect it to do the substitution at 
request time in certain cases instead of only at server startup time  Admittedly 
that would be almost like turning every directive into mod_rewrite, but... an env var 
is an env var, many things are handled at request time so

Dave


At 03:55 AM 9/26/2002 +0200, Dirk-Willem van Gulik wrote:


>On Thu, 26 Sep 2002, [ISO-8859-1] André Malo wrote:
>
>> I'm note sure, but I'd guess this may cause conflicts with mod_rewrite.
>
>Mod rewrite uses % rather than $ for variable names.
>
>It does use $1, $2.. for back references. Which is not a problem as it is
>not followed by a {.
>
>It also uses the dollar for the end of string match. Which thus is thus
>very unlikely to be followed by a { too.
>
>But...  It also uses the $ for ${mapname:key|default} constructs - which
>may cause an issue now. We can make sure that such is ignored; or amend
>the patch to allow a '\' or extra $ to escape either the $ or the {.
>
>> Otherwise...hmm, the feature probably leads to some weird effects, if
>> you forget to set or to remove some env variables...
>
>Aye - this is all about giving a competent admin enough rope to hang
>him/herself - while making sure that a normal user (who is not having any
>${} constructs in his/her file is unaffected.).
>
>Dw

Re: [PATCH] add simple ${ENV} substitution during config file read

[Dirk-Willem van Gulik]

On Thu, 26 Sep 2002, [ISO-8859-1] André Malo wrote:

> I'm note sure, but I'd guess this may cause conflicts with mod_rewrite.

Mod rewrite uses % rather than $ for variable names.

It does use $1, $2.. for back references. Which is not a problem as it is
not followed by a {.

It also uses the dollar for the end of string match. Which thus is thus
very unlikely to be followed by a { too.

But...  It also uses the $ for ${mapname:key|default} constructs - which
may cause an issue now. We can make sure that such is ignored; or amend
the patch to allow a '\' or extra $ to escape either the $ or the {.

> Otherwise...hmm, the feature probably leads to some weird effects, if
> you forget to set or to remove some env variables...

Aye - this is all about giving a competent admin enough rope to hang
him/herself - while making sure that a normal user (who is not having any
${} constructs in his/her file is unaffected.).

Dw

Re: [PATCH] add simple ${ENV} substitution during config file read

[André Malo]

* Dirk-Willem van Gulik wrote:

> In the department of scratching old itches - any strong objections to
> me adding the following patch which allows one to do things like
> 
>  # httpd.conf
>  ServerRoot ${HOME}/apache
>  Port ${PORT:=80}
>  ErrorDocument 500 "Please contact ${CUSTOMER}
> 
> and then
> 
>  [EMAIL PROTECTED] PORT=1234 ./apachectl start
> 
> as few, if any, people use ${FOO} constructs in their configuration
> files today - the change is rather harmless.
> 
> But I've found this useful (since 1.3.9 :-).
> 
> Objections ?

I'm note sure, but I'd guess this may cause conflicts with mod_rewrite.
Otherwise...hmm, the feature probably leads to some weird effects, if
you forget to set or to remove some env variables... 

Perhaps one should turn it on explicitely with a command line parameter?

nd
-- 
s;.*;aoaaaoaaoaaaom:a:alataa:aaoat:a:a:a
maoaa:a:laoata:a:oia:a:o:a:m:a:o:alaoooat:aaool:aaoaa
matooololaaatoto:aaa:o:a:o:m;;s:\s:\::g;y;mailto:;
\40\51/\134\137|ndparker <[EMAIL PROTECTED]>;;print;

UDP ?

[Gregory (Grisha) Trubetskoy]

Has there been any consideration given to supporting UDP, to allow things
like HTTP over UDP as described here:

http://ftp.ics.uci.edu/pub/ietf/http/draft-goland-http-udp-01.txt

The idea of HTTP over UDP may seem irrational, but UPnP (which is the
protocol that is supposed to let your microwave oven discover and control
your dvd player) relies on exclusively on HTTPU, and I was curious whether
httpd could be rigged to be upnp capable.

I saw an earlier short thread about UDP, but could quite figure out where
it ended.

Grisha

Re: Multiple handlers within a module?

[Justin Erenkrantz]

On Wed, Sep 25, 2002 at 03:24:32PM -0700, Will Hartung wrote:
> It is not at all clear to me using the new 2.0 modules how I associate the
> different names to our module. I see the ap_hook_handler(), but it only
> wants the function, and doesn't seem to have a way of binding a name to that
> function.

It doesn't.  All handlers are invoked on all requests.  So, there is
no relationship between the invocation of a handler and whether it
needs to run.  The handler must check whether its handler string is
the same as r->handler.  If not, it is expected to return DECLINED.

> I also noticed within the mod_example, that they check the actual handler
> name when the function is called. Is that necessary? Is that the actual
> mechanism?

Yes.  -- justin

Re: [PATCH] Alerting when fnctl is going bad

[Justin Erenkrantz]

On Thu, Sep 26, 2002 at 03:00:56AM +0200, Dirk-Willem van Gulik wrote:
> Well the numbers in that patch seem to work on sol/bsd/linux since 1.3.9
> under just about any set of circumstances.
> 
> So let's think out of the box then - how can we prevent apache from
> spinning *forever* in that while loop when something has gone astray ?

If I'm understanding you correctly, you want to detect when EINTR
really means "The server is hosed."  What is the correlation?  I
think we should only interpret EINTR as 'try again.'  

If there's an error (i.e. not EINTR) returned by fcntl(), then we'll
handle it accordingly and exit.  But, I just don't see how EINTR (no
matter how many) is indicative of a fatal error.  -- justin

Re: [PATCH] Alerting when fnctl is going bad

[Dirk-Willem van Gulik]

On Wed, 25 Sep 2002, Justin Erenkrantz wrote:

> to let the OS tell us when something has gone afoul rather than
> trying to second-guess it when the error only means "You were
> interrupted - try again."  So, I don't think there is a metric
> that can work (without fail) for this case.  -- justin

Well the numbers in that patch seem to work on sol/bsd/linux since 1.3.9
under just about any set of circumstances.

So let's think out of the box then - how can we prevent apache from
spinning *forever* in that while loop when something has gone astray ?

DW

Re: [PATCH] Alerting when fnctl is going bad

[Justin Erenkrantz]

On Thu, Sep 26, 2002 at 02:48:53AM +0200, Dirk-Willem van Gulik wrote:
> I could not agree more.
> 
> The original patch used 'time' - but that is expensive to calculate. If
> you make a histogram of conseq EINTR over a few weeks you find that
> sequences longer than 5-10 are very rare on a healthy machine. But once
> something runs out of control (say a PHP/sql connector) it shoots in the
> hundreds and thousands for just a single process quickly.
> 
> Suggestions for a better metric (Short of making it self learning ;-).

But, that's heavily dependent on the OS.  Solaris has a tendancy to
have much higher EINTR occurances than other OSes.  So, I'd prefer
to let the OS tell us when something has gone afoul rather than
trying to second-guess it when the error only means "You were
interrupted - try again."  So, I don't think there is a metric
that can work (without fail) for this case.  -- justin

Re: [PATCH] Alerting when fnctl is going bad

[Dirk-Willem van Gulik]

On Wed, 25 Sep 2002, Justin Erenkrantz wrote:

> On Thu, Sep 26, 2002 at 02:11:59AM +0200, Dirk-Willem van Gulik wrote:
> > ->  Makes the wait loop no longer endless - but causes it
> > to bail out (and emit some warnings ahead of time) after
> > a couple of thousand consequituve EINTRs.
>
> Placing a 'magic number' on how many EINTRs is 'failure' doesn't
> seem right.  -- justin

I could not agree more.

The original patch used 'time' - but that is expensive to calculate. If
you make a histogram of conseq EINTR over a few weeks you find that
sequences longer than 5-10 are very rare on a healthy machine. But once
something runs out of control (say a PHP/sql connector) it shoots in the
hundreds and thousands for just a single process quickly.

Suggestions for a better metric (Short of making it self learning ;-).

Dw

[PATCH] add simple ${ENV} substitution during config file read

[Dirk-Willem van Gulik]

In the department of scratching old itches - any strong objections to me
adding the following patch which allows one to do things like

# httpd.conf
ServerRoot ${HOME}/apache
Port ${PORT:=80}
ErrorDocument 500 "Please contact ${CUSTOMER}

and then

[EMAIL PROTECTED] PORT=1234 ./apachectl start

as few, if any, people use ${FOO} constructs in their configuration files
today - the change is rather harmless.

But I've found this useful (since 1.3.9 :-).

Objections ?

Dw

? http_main.c-with-mtext
Index: http_core.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_core.c,v
retrieving revision 1.316
diff -u -r1.316 http_core.c
--- http_core.c 21 Sep 2002 17:18:34 -  1.316
+++ http_core.c 26 Sep 2002 00:45:53 -
@@ -1258,6 +1258,8 @@
  w, NULL);
 }

+line = ap_resolve_env(cmd->pool,line);
+
 /* The entry should be ignored if it is a full URL for a 401 error */

 if (error_number == 401 &&
Index: util.c
===
RCS file: /home/cvs/apache-1.3/src/main/util.c,v
retrieving revision 1.206
diff -u -r1.206 util.c
--- util.c  18 Jun 2002 00:59:58 -  1.206
+++ util.c  26 Sep 2002 00:45:55 -
@@ -756,6 +756,49 @@
 return res;
 }

+/* Check a string for any ${ENV} environment variable
+ * construct and replace each them by the value of
+ * that environment variable, if it exists. If the
+ * environment value does not exist, replace by an
+ * empty string. Any unrecognized construct is not
+ * replaced and silently ignored. Apart from that
+ * simple ${ENV:=defaults} are also possible.
+ */
+API_EXPORT(char *) ap_resolve_env(pool *p, const char * word)
+{
+   char tmp[ MAX_STRING_LEN ];
+   char * s, * e;
+   tmp[0] = '\0';
+
+   if (!(s=strchr(word,'$')))
+   return (char *)word;
+
+   do {
+   /* XXX - relies on strncat() to add '\0'
+*/
+   strncat(tmp,word,s - word);
+
+   if ((s[1] == '{') && (e=strchr(s,'}'))) {
+   char * dfault = "";
+*e = '\0';
+   if ((dfault = strchr(s,':')) && ((dfault[1] == '='))) {
+   *dfault = '\0';
+   dfault +=2;
+   }
+word = e + 1;
+e = getenv(s+2);
+strcat(tmp,e ? e : dfault);
+   } else {
+   /* ignore invalid strings */
+   word = s+1;
+   strcat(tmp,"$");
+   };
+   } while ((s=strchr(word,'$')));
+   strcat(tmp,word);
+
+   return ap_pstrdup(p,tmp);
+}
+
 /* Get a word, (new) config-file style --- quoted strings and backslashes
  * all honored
  */
@@ -775,7 +818,7 @@
 }

 *resp++ = '\0';
-return result;
+return ap_resolve_env(p, result);
 }

 API_EXPORT(char *) ap_getword_conf_nc(pool *p, char **line)

Re: [PATCH] Alerting when fnctl is going bad

[Justin Erenkrantz]

On Thu, Sep 26, 2002 at 02:11:59AM +0200, Dirk-Willem van Gulik wrote:
> ->Makes the wait loop no longer endless - but causes it
>   to bail out (and emit some warnings ahead of time) after
>   a couple of thousand consequituve EINTRs.

Placing a 'magic number' on how many EINTRs is 'failure' doesn't
seem right.  -- justin

[PATCH] Alerting when fnctl is going bad

[Dirk-Willem van Gulik]

Now this may be a bit linux specific - but I'd like to get something like
this in; if needed with a #ifdef DIAG or on a per platform basis.

It is just something I've found to come in handy at various times - in
particular on Linux and with lots of heavy PHP or mod_perl.

This patch does two things

->  Collapes the near identical mutex_fcnt on/off functions
into one.

->  Makes the wait loop no longer endless - but causes it
to bail out (and emit some warnings ahead of time) after
a couple of thousand consequituve EINTRs.

Does this make sense ? Objections ?

Dw

Index: http_main.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_main.c,v
retrieving revision 1.592
diff -u -r1.592 http_main.c
--- http_main.c 21 Sep 2002 17:18:34 -  1.592
+++ http_main.c 26 Sep 2002 00:07:20 -
@@ -885,37 +885,51 @@
 unlink(ap_lock_fname);
 }

-static void accept_mutex_on_fcntl(void)
+static void accept_mutex(struct flock * flag)
 {
-int ret;
-
-while ((ret = fcntl(lock_fd, F_SETLKW, &lock_it)) < 0 && errno == EINTR) {
-   /* nop */
+int ret,count = 0;
+while ((ret = fcntl(lock_fd, F_SETLKW, flag)) < 0 && errno == EINTR) {
+   count++;
+   if (count & 0x20) {
+   ap_log_error(APLOG_MARK,
+   APLOG_INFO|APLOG_NOERRNO,server_conf,
+   "fcntl_mutex(%slock): many EINTR's, keep trying",
+   flag->l_type == F_UNLCK ? "un" : "");
+   if (count > 5000) {
+   ap_log_error(APLOG_MARK,APLOG_EMERG,server_conf,
+   "fcntl_mutex(%slock): %d EINTR's in"
+   " a row, child exiting...",
+   flag->l_type == F_UNLCK ? "un" : "",count);
+   clean_child_exit(APEXIT_CHILDFATAL);
+   }
+   }
 }

 if (ret < 0) {
ap_log_error(APLOG_MARK, APLOG_EMERG, server_conf,
-   "fcntl: F_SETLKW: Error getting accept lock, exiting!  "
-   "Perhaps you need to use the LockFile directive to place "
-   "your lock file on a local disk!");
+   "fcntl: F_SETLKW: Error %slocking accept lock, exiting!  "
+   "Perhaps you need to use the LockFile directive to place "
+   "your lock file on a local disk!",
+   flag->l_type == F_UNLCK ? "un" : "");
clean_child_exit(APEXIT_CHILDFATAL);
 }
+
+if (count > 50) {
+   ap_log_error(APLOG_MARK,APLOG_WARNING|APLOG_NOERRNO,server_conf,
+   "fcntl_mutex(%slock): got EINTR %d consequitive times, "
+   "and finally succeeded",
+   flag->l_type == F_UNLCK ? "un" : "",count);
+   }
 }

-static void accept_mutex_off_fcntl(void)
+static void accept_mutex_on_fcntl(void)
 {
-int ret;
+return accept_mutex(&lock_it);
+}

-while ((ret = fcntl(lock_fd, F_SETLKW, &unlock_it)) < 0 && errno == EINTR) {
-   /* nop */
-}
-if (ret < 0) {
-   ap_log_error(APLOG_MARK, APLOG_EMERG, server_conf,
-   "fcntl: F_SETLKW: Error freeing accept lock, exiting!  "
-   "Perhaps you need to use the LockFile directive to place "
-   "your lock file on a local disk!");
-   clean_child_exit(APEXIT_CHILDFATAL);
-}
+static void accept_mutex_off_fcntl(void)
+{
+return accept_mutex(&unlock_it);
 }

 accept_mutex_methods_s accept_mutex_fcntl_s = {

Re: modules/dav/util/lockview not found

[Günter Knauf]

Hi Astrid,
I've just compiled the dav mopdule for Apache 1.3 and there is the lockview in a 
subdir util, so I assume it was forgotten to add to the Apache2 sources...
you can get the sources from:
http://www.webdav.org/mod_dav/
if you need a Win32 binary tell me.

Guenter.

> The mod_dav documentation mentions a tool lockview to be found at
> modules/dav/util. But I can't found it, neither in the release not at the
> CVS. Does it exist, but has never been committed? Or has it never been
> written?

> Kess

PKCS Mime Types

[Rick Beton]

Hi Guys n Gals,

I'm new to this list. Forgive me therefore if I seem to barge in! :-)

I was wondering about the mime.types configuration file. There are what 
appear to me to be a couple of omissions thus:

application/x-pkcs7-certificates p7b
application/x-x509-email-certpem, cer


because these extensions and Mime Types do seem to be in use. Microsoft 
for example, use the .cer extension.

Regards,
Rick

Multiple handlers within a module?

[Will Hartung]

I'm porting a 1.3 module to 2.0. In our 1.3 module, we have this kind of
structure:

static const handler_rec our_handlers[] =
{
{   "ourthis", HandleThis  },
{   "ourthat", HandleThat},
{   "ourother", HandleOther  },
{   NULL}
};

It is not at all clear to me using the new 2.0 modules how I associate the
different names to our module. I see the ap_hook_handler(), but it only
wants the function, and doesn't seem to have a way of binding a name to that
function.

I also noticed within the mod_example, that they check the actual handler
name when the function is called. Is that necessary? Is that the actual
mechanism?

Any help would be appreciated.

(If this is the wrong list for this, then a pointer to the correct one would
also be appreciated.)

Will Hartung
([EMAIL PROTECTED])

modules/dav/util/lockview not found

[Astrid Kessler]

The mod_dav documentation mentions a tool lockview to be found at 
modules/dav/util. But I can't found it, neither in the release not at the 
CVS. Does it exist, but has never been committed? Or has it never been 
written?

Kess

Re: How Do I Create A Per-Worker Pool?

[Leonardo Javier Belén]

I was wondering that point (and thatr's what I asked Ian). So, the way is to
move to A2, but is it reliable as the 1.3 version, I mean is as stable as
the older brother, or is it under development? I heard it is rock solid, but
I coudnt check.
Thanks in advance. Leo.


- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 25, 2002 4:13 PM
Subject: Re: How Do I Create A Per-Worker Pool?


> This message uses a character set that is not supported by the Internet
> Service.  To view the original message content,  open the attached
> message. If the text doesn't display correctly, save the attachment to
> disk, and then open it using a viewer that can display the original
> character set. <>
>

Re: How Do I Create A Per-Worker Pool?

[rbb]

On Wed, 25 Sep 2002, Ian Holsman wrote:

> Leonardo Javier Belén wrote:
> > I think I have a question to ask associated to this thread: How can I
> > implement a "global pool" of objects. Let me say it better, I want a global
> > pool of database connection, first because I have a limited number of
> > connections and second, because I want to be able to dominate the dbms
> > accesses. All developed as an "ansi C" apache module, but I thing is the
> > same. I'm running Apache 1.3. Is this the same thing? Leonardo Javier Belen.
> > AFIP-AR
> 
> Have a look at apr_reslist.c in the apr-util/misc directory.

apr_reslist.c actually won't work in this case.  He is trying to use
Apache 1.3, which means that the connections would need to be shared
across processes.  In general, it just isn't worth doing a connection pool
with 1.3, because of the overhead of the process model.

Ryan

___
Ryan Bloom  [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---

Re: How Do I Create A Per-Worker Pool?

[Leonardo Javier Belén]

Thanks for the tip, but is this actually Ok if I try to use it on Apache 1.3
Leo.
- Original Message -
From: "Ian Holsman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 25, 2002 4:06 PM
Subject: Re: How Do I Create A Per-Worker Pool?


Leonardo Javier Bel&alefmaks;n wrote:
> I think I have a question to ask associated to this thread: How can I
> implement a "global pool" of objects. Let me say it better, I want a
global
> pool of database connection, first because I have a limited number of
> connections and second, because I want to be able to dominate the dbms
> accesses. All developed as an "ansi C" apache module, but I thing is
the
> same. I'm running Apache 1.3. Is this the same thing? Leonardo Javier
Belen.
> AFIP-AR

Have a look at apr_reslist.c in the apr-util/misc directory.

>
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, September 25, 2002 3:29 PM
> Subject: Re: How Do I Create A Per-Worker Pool?
>
>
>
>>On Wed, 25 Sep 2002, Charles Reitzel wrote:
>>
>>
>>>Hi All,
>>>
>>>This is a thorny (to me) module development question.  I have asked
on
>>
>>the
>>
>>>module list and searched the archives, but have found only a partial
>>>answer.  Any pointers will be appreciated.
>>>
>>>Objective: to create a mutex-free pool per worker in non-MPM-specific
>>
>>way.
>>
>>>I found this exchange in a June posting:
>>>
>Another change we made, as I mentioned in a previous
>Email, was using non-mutexing per-thread memory
>pools (HeapCreate(HEAP_NO_SERIALIZE, ...)). > To get
>best performance with Apache 2 we would really need
>such a memory pool.

And we already have it! Just do:

apr_allocator_t *allocator;
apr_allocator_create(&allocator);
apr_pool_create_ex(&pool, parent_pool, abort_fn, allocator);
apr_allocator_owner_set(allocator, pool);

Now you have a mutexless allocator associated with a pool. All child
>>
>>pools
>>
of this pool will use the same allocator and will therefor also have
>>
>>no mutex.
>>
>>>Looks good.  But I have questions.  What is the correct place to put
>>
>>this
>>
>>>code and where do keep the pool pointer afterwards.  I.e. how do you
>>
>>find
>>
>>>the pool from within a module handler?
>>>
>>>
>>>To my mind, the Apache module API is missing an important data
>>
>>structure:
>>
>>>worker_rec.   It is obviously redundant (but does no harm) in the
>>
>>prefork
>>
>>>MPM, but is a necessary ingredient in _any_ threaded MPM.  Such a
>>
>>structure
>>
>>>would allow modules to be written as thread-safe - independent of the
>>
>>MPM
>>
>>>currently configured by the user.  The request record could and
should
>>
>>>contain a pointer to the current worker for easy access.  In the
>>
>>absence of
>>
>>>a worker_rec, however, some guidance on the above would be helpful.
>>>
>>
>>The structures in Apache are designed around an HTTP request, not the
>>entity that is running the request.  Every threaded MPM has a pool for
>>each thread, which does allow for thread-safe programming.
>>
>>Why exactly would you want a worker_rec?  What problem are you having?
>>
>>Ryan
>>
>>__
__
>>___
>>Ryan Bloom[EMAIL PROTECTED]
>>550 Jean St
>>Oakland CA 94610
>>--
--
>>---
>
>

Re: How Do I Create A Per-Worker Pool?

[Ian Holsman]

Leonardo Javier Bel&alefmaks;n wrote:
> I think I have a question to ask associated to this thread: How can I
> implement a "global pool" of objects. Let me say it better, I want a global
> pool of database connection, first because I have a limited number of
> connections and second, because I want to be able to dominate the dbms
> accesses. All developed as an "ansi C" apache module, but I thing is the
> same. I'm running Apache 1.3. Is this the same thing? Leonardo Javier Belen.
> AFIP-AR

Have a look at apr_reslist.c in the apr-util/misc directory.

> 
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, September 25, 2002 3:29 PM
> Subject: Re: How Do I Create A Per-Worker Pool?
> 
> 
> 
>>On Wed, 25 Sep 2002, Charles Reitzel wrote:
>>
>>
>>>Hi All,
>>>
>>>This is a thorny (to me) module development question.  I have asked on
>>
>>the
>>
>>>module list and searched the archives, but have found only a partial
>>>answer.  Any pointers will be appreciated.
>>>
>>>Objective: to create a mutex-free pool per worker in non-MPM-specific
>>
>>way.
>>
>>>I found this exchange in a June posting:
>>>
>Another change we made, as I mentioned in a previous
>Email, was using non-mutexing per-thread memory
>pools (HeapCreate(HEAP_NO_SERIALIZE, ...)). > To get
>best performance with Apache 2 we would really need
>such a memory pool.

And we already have it! Just do:

apr_allocator_t *allocator;
apr_allocator_create(&allocator);
apr_pool_create_ex(&pool, parent_pool, abort_fn, allocator);
apr_allocator_owner_set(allocator, pool);

Now you have a mutexless allocator associated with a pool. All child
>>
>>pools
>>
of this pool will use the same allocator and will therefor also have
>>
>>no mutex.
>>
>>>Looks good.  But I have questions.  What is the correct place to put
>>
>>this
>>
>>>code and where do keep the pool pointer afterwards.  I.e. how do you
>>
>>find
>>
>>>the pool from within a module handler?
>>>
>>>
>>>To my mind, the Apache module API is missing an important data
>>
>>structure:
>>
>>>worker_rec.   It is obviously redundant (but does no harm) in the
>>
>>prefork
>>
>>>MPM, but is a necessary ingredient in _any_ threaded MPM.  Such a
>>
>>structure
>>
>>>would allow modules to be written as thread-safe - independent of the
>>
>>MPM
>>
>>>currently configured by the user.  The request record could and should
>>
>>>contain a pointer to the current worker for easy access.  In the
>>
>>absence of
>>
>>>a worker_rec, however, some guidance on the above would be helpful.
>>>
>>
>>The structures in Apache are designed around an HTTP request, not the
>>entity that is running the request.  Every threaded MPM has a pool for
>>each thread, which does allow for thread-safe programming.
>>
>>Why exactly would you want a worker_rec?  What problem are you having?
>>
>>Ryan
>>
>>
>>___
>>Ryan Bloom[EMAIL PROTECTED]
>>550 Jean St
>>Oakland CA 94610
>>
>>---
> 
> 

Re: How Do I Create A Per-Worker Pool?

[Leonardo Javier Belén]

I think I have a question to ask associated to this thread: How can I
implement a "global pool" of objects. Let me say it better, I want a global
pool of database connection, first because I have a limited number of
connections and second, because I want to be able to dominate the dbms
accesses. All developed as an "ansi C" apache module, but I thing is the
same. I'm running Apache 1.3. Is this the same thing? Leonardo Javier Belen.
AFIP-AR

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 25, 2002 3:29 PM
Subject: Re: How Do I Create A Per-Worker Pool?


> On Wed, 25 Sep 2002, Charles Reitzel wrote:
>
> > Hi All,
> >
> > This is a thorny (to me) module development question.  I have asked on
> the
> > module list and searched the archives, but have found only a partial
> > answer.  Any pointers will be appreciated.
> >
> > Objective: to create a mutex-free pool per worker in non-MPM-specific
> way.
> >
> > I found this exchange in a June posting:
> > > > Another change we made, as I mentioned in a previous
> > > > Email, was using non-mutexing per-thread memory
> > > > pools (HeapCreate(HEAP_NO_SERIALIZE, ...)). > To get
> > > > best performance with Apache 2 we would really need
> > > > such a memory pool.
> > >
> > >And we already have it! Just do:
> > >
> > > apr_allocator_t *allocator;
> > > apr_allocator_create(&allocator);
> > > apr_pool_create_ex(&pool, parent_pool, abort_fn, allocator);
> > > apr_allocator_owner_set(allocator, pool);
> > >
> > >Now you have a mutexless allocator associated with a pool. All child
> pools
> > >of this pool will use the same allocator and will therefor also have
> no mutex.
> >
> > Looks good.  But I have questions.  What is the correct place to put
> this
> > code and where do keep the pool pointer afterwards.  I.e. how do you
> find
> > the pool from within a module handler?
> >
> > 
> > To my mind, the Apache module API is missing an important data
> structure:
> > worker_rec.   It is obviously redundant (but does no harm) in the
> prefork
> > MPM, but is a necessary ingredient in _any_ threaded MPM.  Such a
> structure
> > would allow modules to be written as thread-safe - independent of the
> MPM
> > currently configured by the user.  The request record could and should
>
> > contain a pointer to the current worker for easy access.  In the
> absence of
> > a worker_rec, however, some guidance on the above would be helpful.
> > 
>
> The structures in Apache are designed around an HTTP request, not the
> entity that is running the request.  Every threaded MPM has a pool for
> each thread, which does allow for thread-safe programming.
>
> Why exactly would you want a worker_rec?  What problem are you having?
>
> Ryan
>
> 
> ___
> Ryan Bloom[EMAIL PROTECTED]
> 550 Jean St
> Oakland CA 94610
> 
> ---

Re: How Do I Create A Per-Worker Pool?

[rbb]

On Wed, 25 Sep 2002, Charles Reitzel wrote:

> Hi All,
> 
> This is a thorny (to me) module development question.  I have asked on the 
> module list and searched the archives, but have found only a partial 
> answer.  Any pointers will be appreciated.
> 
> Objective: to create a mutex-free pool per worker in non-MPM-specific way.
> 
> I found this exchange in a June posting:
> > > Another change we made, as I mentioned in a previous
> > > Email, was using non-mutexing per-thread memory
> > > pools (HeapCreate(HEAP_NO_SERIALIZE, ...)). > To get
> > > best performance with Apache 2 we would really need
> > > such a memory pool.
> >
> >And we already have it! Just do:
> >
> > apr_allocator_t *allocator;
> > apr_allocator_create(&allocator);
> > apr_pool_create_ex(&pool, parent_pool, abort_fn, allocator);
> > apr_allocator_owner_set(allocator, pool);
> >
> >Now you have a mutexless allocator associated with a pool. All child pools 
> >of this pool will use the same allocator and will therefor also have no mutex.
> 
> Looks good.  But I have questions.  What is the correct place to put this 
> code and where do keep the pool pointer afterwards.  I.e. how do you find 
> the pool from within a module handler?
> 
> 
> To my mind, the Apache module API is missing an important data structure: 
> worker_rec.   It is obviously redundant (but does no harm) in the prefork 
> MPM, but is a necessary ingredient in _any_ threaded MPM.  Such a structure 
> would allow modules to be written as thread-safe - independent of the MPM 
> currently configured by the user.  The request record could and should 
> contain a pointer to the current worker for easy access.  In the absence of 
> a worker_rec, however, some guidance on the above would be helpful.
> 

The structures in Apache are designed around an HTTP request, not the
entity that is running the request.  Every threaded MPM has a pool for
each thread, which does allow for thread-safe programming.

Why exactly would you want a worker_rec?  What problem are you having?

Ryan

___
Ryan Bloom  [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---

How Do I Create A Per-Worker Pool?

[Charles Reitzel]

Hi All,

This is a thorny (to me) module development question.  I have asked on the 
module list and searched the archives, but have found only a partial 
answer.  Any pointers will be appreciated.

Objective: to create a mutex-free pool per worker in non-MPM-specific way.

I found this exchange in a June posting:
> > Another change we made, as I mentioned in a previous
> > Email, was using non-mutexing per-thread memory
> > pools (HeapCreate(HEAP_NO_SERIALIZE, ...)). > To get
> > best performance with Apache 2 we would really need
> > such a memory pool.
>
>And we already have it! Just do:
>
> apr_allocator_t *allocator;
> apr_allocator_create(&allocator);
> apr_pool_create_ex(&pool, parent_pool, abort_fn, allocator);
> apr_allocator_owner_set(allocator, pool);
>
>Now you have a mutexless allocator associated with a pool. All child pools 
>of this pool will use the same allocator and will therefor also have no mutex.

Looks good.  But I have questions.  What is the correct place to put this 
code and where do keep the pool pointer afterwards.  I.e. how do you find 
the pool from within a module handler?


To my mind, the Apache module API is missing an important data structure: 
worker_rec.   It is obviously redundant (but does no harm) in the prefork 
MPM, but is a necessary ingredient in _any_ threaded MPM.  Such a structure 
would allow modules to be written as thread-safe - independent of the MPM 
currently configured by the user.  The request record could and should 
contain a pointer to the current worker for easy access.  In the absence of 
a worker_rec, however, some guidance on the above would be helpful.


thanks,
Charlie

Re: [PATCH] Be more lenient with ap_proxy_read_headers in 2.0

[Jim Jagielski]

At 6:16 PM +0200 9/25/02, Graham Leggett wrote:
>
>The above two cases of brokenness are mutually exclusive. If a non-header is 
>encountered when a header is expected, we have the choice of either assuming it's a 
>header and ignoring it, or assuming the headers are over and starting the body. We 
>cannot do both at the same time.

The patch would do the latter. The sole exception is that if it sees
the HTTP/1.1 response again, it ignores that. Otherwise, game over.

>What's more there is a feeling out there that it is Apache's responsiblity to "fix" 
>all the broken servers out there. I believe it is not. It makes sense to be lenient 
>in what we accept, but to accept any old rubbish given to us is just wrong.
>

Oh, I agree. See my comments on Bugz 11800. The *only* reason why
I'm leaning towards "fixing" that (and that is *not* the right word,
since "fix" implies something is broken, which is not the case here)
is that 1.3 is, in this case, more robust than 2.0 is. Migration to 2.0
is not an option for those who tickle this bug, and they are "stuck"
with 1.3. Simple on that basis is why I created and posted the patch.

I agree that we cannot and should not fix or work-around everything that's
broken out there, but the 1.3 argument sometimes is enough...
-- 
===
   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: Patch mod_proxy: mod_proxy + mod_cache problem

[Graham Leggett]

Matthieu Estrade wrote:

> My problem is i can't setup the filter cache_in_filter to be executed 
> after mod_proxy pass his "last" brigade to the filter chain

That's because there is never any such thing as the "last" brigade. 
Responses are not limited by length anywhere within the filter 
subsystem, this is the whole point behind using brigades - long 
neverending chains of data that can be of any length, even bigger than 
available RAM.

The cache filter works (should work) along the idea that each brigade is 
simply added to the one before. If this gets too big, we throw it away 
and the object is no longer cached.

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight..."

Re: [PATCH] Be more lenient with ap_proxy_read_headers in 2.0

[Graham Leggett]

Peter Van Biesen wrote:

> I've sent a patch doing the same some time ago, but it was not accepted
> so don't get your hopes up ;-). 

The big problem is that the code is starting to be so lenient it is 
getting silly.

If a bogus header comes along (ie a header without a ":" in it) it is 
relatively safe and easy to throw it away and ignore that specific 
header. AFAIK there is code in there that already does that, and if it 
doesn't such a change should not be too hard to put in.

However, the blank line after the headers is the key indicator that the 
headers are finished and the body is starting. If a server out there 
"forgets" this blank line, there is no way we can reliably tell that the 
headers have ended, which means we are probably going to be sending 
garbage to the downstream browser as a result anyway.

The above two cases of brokenness are mutually exclusive. If a 
non-header is encountered when a header is expected, we have the choice 
of either assuming it's a header and ignoring it, or assuming the 
headers are over and starting the body. We cannot do both at the same time.

What's more there is a feeling out there that it is Apache's 
responsiblity to "fix" all the broken servers out there. I believe it is 
not. It makes sense to be lenient in what we accept, but to accept any 
old rubbish given to us is just wrong.

Hopefully this explains the reasons why some of the patches have not 
been committed.

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight..."

Re: Patch mod_proxy: mod_proxy + mod_cache problem

[Graham Leggett]

Ian Holsman wrote:

>> The cache filter is supposed to run after all the filters for maximum 
>> caching advantage.
>>
> I disagree on this. the cache filter should be able to placed where the 
> admin wants it.

In the advanced case, yes - but in the simplest 
turn-it-on-and-it-should-just-work case the cache should be as optimised 
as possible.

> what the code should do is remember which filters where placed above the 
> cache_input filter, and restore these filters on cache_output.

This starts getting complex.

The original idea for the cache was to be transparent public proxy cache 
  layered between Apache and the browser. Because RFC2616 dictates how 
such a proxy cache should work, determining whether we have done the 
"right" thing should be relatively easy.

As we move the caching filters further towards the core of Apache, 
suddenly things start to get complicated, as there is no longer a 
guarantee that the point into which cache has been inserted is compliant 
with RFC2616 in the first place, which in turn makes things less likely 
to work predictably or correctly.

Yes, being able to put the cache wherever the admin wants is in theory a 
nice thing to have, actually practically achieving this is something 
that's going to have to be looked at pretty carefully.

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight..."

Re: Default character sets..

[Joshua Slive]

Erik Parker wrote:
> I hate to reply to my own post, but because of my apparent crack habits.. I
> didn't realize the testing environment configs weren't nearly exact..
> 
> The http 2.0 server still had a AddDefaultChar set lower in the config file.
> 
> 
> So.. the only issue/question is..
> 
> When setting AddDefcultCharset, why doesn't it apply to error responses?

I believe this was recently covered on this list.  AddDefaultCharset 
doesn't apply to the "internal" error responses because those responses 
are written in a specific character-set (ISO-8859-1).  The character set 
is known, so it doesn't make sense to use any other.

Joshua.

RE: Default character sets..

[Bill Stoddard]

> I hate to reply to my own post, but because of my apparent crack
> habits.. I
> didn't realize the testing environment configs weren't nearly exact..
>
> The http 2.0 server still had a AddDefaultChar set lower in the
> config file.
>
>
> So.. the only issue/question is..
>
> When setting AddDefcultCharset, why doesn't it apply to error responses?

Because the error messages are charset text/html in iso8859-1?

Are you by chance looking at a problem with redirecting old Netscape
browsers to sites in a different languages?

Bill

Re: suexec and vhosts?

[Colm MacCárthaigh]

On Tue, Sep 24, 2002 at 11:39:22PM -0700, Justin Erenkrantz wrote:
> Is it possible to use SuexecUserGroup in combination with a vhost
> that isn't served out of the default htdocs dir on a per-vhost level?
> This is a rhetorical question as modules/generators/mod_suexec.c:110
> forbids this.

It's possible, it's all down to what you set suexec-docroot to.
If you set it to / then everything is good. I set mine to the same
as my prefix, and drop all of my vhosts in a $prefix/vhosts/  
directory, which keeps them away from htdocs. So you don't
need to heep suexec'd vhosts in the same place as your DocumentRoot.

> The intention is to have multiple vhosts which each have their own
> user associated with them with independent docroots
> (~user/public_html).  So when a CGI page goes to that vhost, the
> CGIs would be executed as the associated user.

Doing that, you'd have to give each one an explicit SuexecUserGroup
directive and change the suexec-docroot to /home or / , depending
on where else you'd like vhosts to live aswell.

> Hmm, why does this eerily sound like the perchild MPM (what little I
> know of it)?  But, it seems that suexec could easily handle this
> case too with a little bit of tweaking.  So, my question is why
> do we set cfg->ugid.userdir = 0 when it could be useful to set it
> to 1?  Could we add a directive (SuexecUseUserDoc) for this case? 

If userdir was enabled, it wouldnt work, since you would
have to prepend the tilde to the uid. How would you decide
which user to accociate with an arbitrary directory ? Multiple
uid's could point to it as being in $home, going with ownership
kills one of the points of using directives like this (so
that CGI no longer have write perms on what it's reading). 

I think a way to go about solving the problem would be
to modify suexec (not the module) to work when PWD is in
$home for the target uid even without a tilde. 

Tied in with all of this there's still the larger problem
of how mod_suexec should handle the SuexecUserGroup directive
when userdir and an explicit directive are both there. In you're
examples it could get very confusing. 

Comments in PR 9038 describe the problem in detail. 

> For now, mod_rewrite has been jury-rigged to rewrite the CGI requests
> so that these request end up as vhost/~user/ so the mod_userdir rule
> hits.  But, that's clunky.  -- justin

That it is :( Though, I'm running over 300 of these on my server
and it's working out quiet well, some of them are reverse proxies,
some not so, but yes it is clunky.

-- 
[EMAIL PROTECTED]PubKey: [EMAIL PROTECTED]  
Web: http://devnull.redbrick.dcu.ie/ 

Re: graceful?

[Ask Bjoern Hansen]

On Mon, 23 Sep 2002 [EMAIL PROTECTED] wrote:

> > Has anybody torture tested graceful restarts lately?  I only ask because
> > we just got a PR that gave me "that sinking feeling".  Maybe not a real
> > problem, but just figured I'd ask.
>
> They work on daedalus with prefork.  But that's typically just once a night -
> not sure if that qualifies as a torture test.

It fails sometimes for me on Linux (pretty standard RedHat 7.3)
with the worker MPM. (The original "parent" process (if that's what
you call it) just hangs until you kill it).

Actually, it might not have failed since sometime around .40; I
haven't paid that much attention.  I will try to look closer if it
happens again.


(how was that for a useless bug report? :-) )

 - ask

-- 
ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();