Re: Mod_auth_digest URI Mismatch

[André Malo]

* Rob Emanuele wrote:

> Thanks.  I found that too.  Is this listed anywhere in Microsoft's
> Knowledge Base?

hmm, don't know. Didn't find anything there.

> Any suggestions for a workaround?

forms: use POST
simple URLs: use mod_rewrite or something to provide the browser a URL 
without query strings.

(client-side: use another browser ;-)

nd
-- 
Real programmers confuse Christmas and Halloween because
DEC 25 = OCT 31.  -- Unknown

  (found in ssl_engine_mutex.c)

RE: [PATCH] move CachemaxStreamingBuffer from mod_cachetomod_mem_cache

[Brian Pane]

On Tue, 2002-12-17 at 13:56, Bill Stoddard wrote:
> New patch but one small change that you can make by hand.  Here is the portion
> of the patch that changed...

Thanks, it works now.  I also tested the case where the response
size ends up exceeding the MCacheMaxStreamingBuffer size, and that
worked properly too.

+1 for the patch

Brian

RE: [PATCH] move CachemaxStreamingBuffer from mod_cache tomod_mem_cache

[Bill Stoddard]

New patch but one small change that you can make by hand.  Here is the portion
of the patch that changed...

@@ -449,12 +454,22 @@
 return DECLINED;
 }

+if (len == -1) {
+/* Caching a streaming response. Assume the response is
+ * less than or equal to max_streaming_buffer_size. We will
+ * correct all the cache size counters in write_body once
+ * we know exactly know how much we are caching.
+ */
+len = sconf->max_streaming_buffer_size;
+}
+


>
>
> On Tue, 2002-12-17 at 12:35, Bill Stoddard wrote:
> > This patch does the following:
> >
> > 1. Renames CacheMaxStreamingBuffer to MCacheMaxStreamingBuffer
> >
> > 2. Moves implementation of MCacheMaxStreamingBuffer from mod_cache to
> > mod_mem_cache
> >
> > 3. Implements default value of MCacheMaxStreamingBuffer (10
> bytes) which is
> > adjusted downward if the default exceeds the setting of
> MCacheMaxCacheObjectSize
> > (I was not too keen on setting default MCacheMaxStreamingBuffer to
> be equal to
> > MCacheMaxCacheObjectSize for reasons pointed out by Brian Pane).
> >
> > The patch is filtered to ignore changes in spacing (cvs diff -u -b). I still
> > have a bit of cleanup to do in the cache size check area (I am not
> convinced the
> > original code worked all that well) and I'm planning on fixing that
> tomorrow.
>
> I just tested this patch, and it doesn't seem to cache
> responses that span multiple brigades.
>
> Configuration:
>
> 
> CacheEnable mem /
> MCacheSize 4096
> MCacheMaxObjectCount 100
> MCacheMinObjectSize 1
> MCacheMaxObjectSize 16384
> MCacheMaxStreamingBuffer 10300
> 
>
> 
> AddOutputFilter BUCKETEER .html
> 
>
> Test case:
>   1. Create a 1024-byte file
>   2. Put a Ctrl-F in the middle of it (so that mod_bucketeer
>  will split the file and flush the first brigade)
>   3. Request the file
>
> Result:
> [Tue Dec 17 14:07:57 2002] [debug] mod_mem_cache.c(475): cache_mem: URL
> /1k.html? failed the size check, or is incomplete
>
> Without any mod_bucketeer intervention, mod_mem_cache caches
> the file successfully.
>
> Brian
>



cache.patch
Description: Binary data

RE: [PATCH] move CachemaxStreamingBuffer from mod_cache tomod_mem_cache

[Bill Stoddard]

I see what's wrong. Will post an updated patch ASAP.

Bill

>
> On Tue, 2002-12-17 at 12:35, Bill Stoddard wrote:
> > This patch does the following:
> >
> > 1. Renames CacheMaxStreamingBuffer to MCacheMaxStreamingBuffer
> >
> > 2. Moves implementation of MCacheMaxStreamingBuffer from mod_cache to
> > mod_mem_cache
> >
> > 3. Implements default value of MCacheMaxStreamingBuffer (10
> bytes) which is
> > adjusted downward if the default exceeds the setting of
> MCacheMaxCacheObjectSize
> > (I was not too keen on setting default MCacheMaxStreamingBuffer to
> be equal to
> > MCacheMaxCacheObjectSize for reasons pointed out by Brian Pane).
> >
> > The patch is filtered to ignore changes in spacing (cvs diff -u -b). I still
> > have a bit of cleanup to do in the cache size check area (I am not
> convinced the
> > original code worked all that well) and I'm planning on fixing that
> tomorrow.
>
> I just tested this patch, and it doesn't seem to cache
> responses that span multiple brigades.
>
> Configuration:
>
> 
> CacheEnable mem /
> MCacheSize 4096
> MCacheMaxObjectCount 100
> MCacheMinObjectSize 1
> MCacheMaxObjectSize 16384
> MCacheMaxStreamingBuffer 10300
> 
>
> 
> AddOutputFilter BUCKETEER .html
> 
>
> Test case:
>   1. Create a 1024-byte file
>   2. Put a Ctrl-F in the middle of it (so that mod_bucketeer
>  will split the file and flush the first brigade)
>   3. Request the file
>
> Result:
> [Tue Dec 17 14:07:57 2002] [debug] mod_mem_cache.c(475): cache_mem: URL
> /1k.html? failed the size check, or is incomplete
>
> Without any mod_bucketeer intervention, mod_mem_cache caches
> the file successfully.
>
> Brian
>

Re: [PATCH] move CachemaxStreamingBuffer from mod_cache tomod_mem_cache

[Brian Pane]

On Tue, 2002-12-17 at 12:35, Bill Stoddard wrote:
> This patch does the following:
> 
> 1. Renames CacheMaxStreamingBuffer to MCacheMaxStreamingBuffer
> 
> 2. Moves implementation of MCacheMaxStreamingBuffer from mod_cache to
> mod_mem_cache
> 
> 3. Implements default value of MCacheMaxStreamingBuffer (10 bytes) which is
> adjusted downward if the default exceeds the setting of MCacheMaxCacheObjectSize
> (I was not too keen on setting default MCacheMaxStreamingBuffer to be equal to
> MCacheMaxCacheObjectSize for reasons pointed out by Brian Pane).
> 
> The patch is filtered to ignore changes in spacing (cvs diff -u -b). I still
> have a bit of cleanup to do in the cache size check area (I am not convinced the
> original code worked all that well) and I'm planning on fixing that tomorrow.

I just tested this patch, and it doesn't seem to cache
responses that span multiple brigades.

Configuration:


CacheEnable mem /
MCacheSize 4096
MCacheMaxObjectCount 100
MCacheMinObjectSize 1
MCacheMaxObjectSize 16384
MCacheMaxStreamingBuffer 10300



AddOutputFilter BUCKETEER .html


Test case:
  1. Create a 1024-byte file
  2. Put a Ctrl-F in the middle of it (so that mod_bucketeer
 will split the file and flush the first brigade)
  3. Request the file

Result:
[Tue Dec 17 14:07:57 2002] [debug] mod_mem_cache.c(475): cache_mem: URL
/1k.html? failed the size check, or is incomplete

Without any mod_bucketeer intervention, mod_mem_cache caches
the file successfully.

Brian

RE: Memory leak on Windows [Bugzilla #11427]

[Alex Varju]

Hi Bill,

Thank you for looking at this.

I've just grabbed the httpd-2.0, apr, apr-util, and apr-iconv modules from
CVS (-rHEAD).  With the same configuration file as I was using in 2.0.43,
I can still reproduce the problem.

I then added 'KeepAlive off' to my configuration file.  With this setting,
the problem continues to display itself on my server.  With 'KeepAlive on'
and 'MaxKeepAliveRequests 10' in my configuration file, again the problem
continues.

I am running two different tests to reproduce this, although they may not
be related.  In the first test, I have a client machine running
SilkPerformer which opens up several parallel requests to the server.  In
the second test, I use Internet Explorer and hold down the F5 key for a
few seconds straight .. I think this triggers the client abort code inside
Apache.

Any other suggestions?  My plan now is to walk through all the memory
allocations in the call stack in the hopes that I find something using a
pool that doesn't get released.  I'm definitely not looking forward to
this.

Thanks,
Alex.

On Tue, 17 Dec 2002, Bill Stoddard wrote:

> I am running 2.0.44-dev (latest snapshot in CVS from just a few minutes ago) and
> I'm not able to recreate this problem. Have you tried the latest version of 2.0
> (CVS HEAD)?  Just for fun, try disabling keep-alive connections or set
> MaxKeepAliveRequests to a small value (maybe from the default of 100 to 10) and
> report back the results.
>
> Bill
>
> >
> > Hi,
> >
> > I'm still trying to track the cause of this problem down, and I'm hoping
> > somebody around here can help me.
> >
> > To summarize, I'm seeing Apache's memory footprint grow abnormally large
> > on Windows when using CGIs.  The size of the growth seems to be
> > proportional to the amount of data printed to stdout from the CGI.
> >
> > Some sample data:
> >  - With 16 threads and 1 meg sent to stdout, combined physical and virtual
> >memory reaches about 70 megs after hammering the server for several
> >minutes
> >  - If I increase the amount of stdout data to 2 megs, the process grows to
> >about 130 megs within another few minutes.
> >
> > I've spent the last few days reviewing the code, and I'm a bit confused
> > about the mpm_winnt pool cleanup code.  I haven't spent a lot of time
> > reading the code in the past, so there's a good chance that I've just
> > missed something.  As far as I can tell, ap_read_request() creates the
> > request pool, but nothing explicitly cleans it up.  Instead, it looks like
> > mpm_recycle_completion_context() clears the ptrans pool the next time the
> > thread handles a request.  While this seems funny to me, I don't see why
> > some of the memory would fail to be released.
> >
> > I've tried to simplify my httpd.conf file to reduce the test case:
> >
> >   ServerRoot c:/varju/webct/webct/server
> >   ThreadsPerChild 16
> >   LoadModule cgi_module modules/mod_cgi.so
> >   LoadModule alias_module modules/mod_alias.so
> >   Listen 80
> >   ScriptAlias /test.pl c:/varju/webct/webct/webct/generic/public/test.pl
> >
> > Can anybody offer me suggestions of where to look next?
> >
> > Thanks,
> > Alex.
>
>

[PATCH] move CachemaxStreamingBuffer from mod_cache to mod_mem_cache

[Bill Stoddard]

This patch does the following:

1. Renames CacheMaxStreamingBuffer to MCacheMaxStreamingBuffer

2. Moves implementation of MCacheMaxStreamingBuffer from mod_cache to
mod_mem_cache

3. Implements default value of MCacheMaxStreamingBuffer (10 bytes) which is
adjusted downward if the default exceeds the setting of MCacheMaxCacheObjectSize
(I was not too keen on setting default MCacheMaxStreamingBuffer to be equal to
MCacheMaxCacheObjectSize for reasons pointed out by Brian Pane).

The patch is filtered to ignore changes in spacing (cvs diff -u -b). I still
have a bit of cleanup to do in the cache size check area (I am not convinced the
original code worked all that well) and I'm planning on fixing that tomorrow.

Index: cache_cache.c
===
RCS file: /home/cvs/httpd-2.0/modules/experimental/cache_cache.c,v
retrieving revision 1.2
diff -u -b -r1.2 cache_cache.c
--- cache_cache.c   18 Aug 2002 03:23:06 -  1.2
+++ cache_cache.c   17 Dec 2002 21:03:40 -
@@ -101,6 +101,7 @@
 ((c->current_size + c->size_entry(entry)) > c->max_size)) {

 ejected = cache_pq_pop(c->pq);
+/* What if ejected is NULL? */
 priority = c->get_pri(ejected);

 if (c->queue_clock < priority)
Index: mod_cache.c
===
RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_cache.c,v
retrieving revision 1.71
diff -u -b -r1.71 mod_cache.c
--- mod_cache.c 17 Dec 2002 19:12:38 -  1.71
+++ mod_cache.c 17 Dec 2002 21:03:40 -
@@ -421,13 +421,13 @@
 cache_request_rec *cache;
 cache_server_conf *conf;
 char *url = r->unparsed_uri;
-const char *cc_out;
+const char *cc_out, *cl;
 const char *exps, *lastmods, *dates, *etag;
 apr_time_t exp, date, lastmod, now;
 apr_off_t size;
 cache_info *info;
-
-apr_bucket *split_point = NULL;
+char *reason;
+apr_pool_t *p;

 /* check first whether running this filter has any point or not */
 if(r->no_cache) {
@@ -445,17 +445,8 @@
 ap_set_module_config(r->request_config, &cache_module, cache);
 }

-/* If we've previously processed and set aside part of this
- * response, skip the cacheability checks
- */
-if (cache->saved_brigade != NULL) {
-exp = cache->exp;
-lastmod = cache->lastmod;
-info = cache->info;
-}
-else {
-char *reason = NULL;
-apr_pool_t *p = r->pool;
+reason = NULL;
+p = r->pool;
 /*
  * Pass Data to Cache
  * --
@@ -611,22 +602,14 @@
 return ap_pass_brigade(f->next, in);
 }
 cache->in_checked = 1;
-} /* if cache->saved_brigade==NULL */

-/* Set the content length if known.  We almost certainly do NOT want to
- * cache streams with unknown content lengths in the in-memory cache.
- * Streams with unknown content length should be first cached in the
- * file system. If they are withing acceptable limits, then they can be
- * moved to the in-memory cache.
+/* Set the content length if known.
  */
-{
-const char* cl;
 cl = apr_table_get(r->headers_out, "Content-Length");
 if (cl) {
 size = apr_atoi64(cl);
 }
 else {
-
 /* if we don't get the content-length, see if we have all the
  * buckets and use their length to calculate the size
  */
@@ -648,108 +631,8 @@
 }
 size += e->length;
 }
-
 if (!all_buckets_here) {
-/* Attempt to set aside a copy of a partial response
- * in hopes of caching it once the rest of the response
- * is available.  There are special cases in which we
- * don't try to set aside the content, though:
- *   1. The brigade contains at least one bucket of
- *  unknown length, such as a pipe or socket bucket.
- *   2. The size of the response exceeds the limit set
- *  by the CacheMaxStreamingBuffer  directive.
- */
-if (unresolved_length ||
-(cache->saved_size + size >
- conf->max_streaming_buffer_size)) {
-
-ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r->server,
- "cache: not caching streamed response for "
- "%s because length %s", url,
- (unresolved_length ?
-  "cannot be determined" :
-  "> CacheMaxStreamingBuffer"));
-
-if (cache->saved_brigade != NULL) {
-apr_brigade_destroy(cache->saved_brigade);
-cache->saved_brigade = NULL;
-cache->save

Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c

[Cliff Woolley]

On Tue, 17 Dec 2002, Greg Marr wrote:

> Any reason not to just use apr_pstrcat(p, "Broken expires header ",
> exps) and save the overhead of the psprintf?

None that I know of.  It's not the main-line case, so it's not the most
critical thing in the world performance-wise, but I suppose it couldn't
hurt.  Anyway, wouldn't it be:

apr_pstrcat(p, "Broken expires header ", exps, NULL);

I was pretty sure you need the NULL there for pstrcat.

--Cliff

Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c

[Greg Marr]

At 02:23 PM 12/17/2002, Paul J. Reder wrote:

Yup, the coredump happened in the first call with the %d. I just 
patched this second call without looking at the exp parm, then 
failed to notice the warning... *sigh* must be near Christmas 
vacation when it takes three passes to get something like this 
right... ;)

Any reason not to just use apr_pstrcat(p, "Broken expires header ", 
exps) and save the overhead of the psprintf?

Cliff Woolley wrote:


On Tue, 17 Dec 2002, Joe Orton wrote:


On Tue, Dec 17, 2002 at 05:10:05PM -, Bill Stoddard wrote:


  else if (exps != NULL && exp == APR_DATE_BAD) {
  /* if a broken Expires header is present, don't 
cache it */
 -reason = apr_pstrcat(p, "Broken expires header 
%s", exp);
 +reason = apr_psprintf(p, "Broken expires header 
%s", exp);
Still not right - 'exp' is an apr_time_t, you mean 'exps' I guess?

mod_cache.c: In function `cache_in_filter':
mod_cache.c:543: warning: format argument is not a pointer (arg 3)


Oooh, yowtch... good call.  I wasn't even looking at that part.


--
Greg Marr
[EMAIL PROTECTED]

Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c

[Paul J. Reder]

Yup, the coredump happened in the first call with the %d. I just
patched this second call without looking at the exp parm, then failed
to notice the warning... *sigh* must be near Christmas vacation
when it takes three passes to get something like this right... ;)

Cliff Woolley wrote:


On Tue, 17 Dec 2002, Joe Orton wrote:



On Tue, Dec 17, 2002 at 05:10:05PM -, Bill Stoddard wrote:


  else if (exps != NULL && exp == APR_DATE_BAD) {
  /* if a broken Expires header is present, don't cache it */
 -reason = apr_pstrcat(p, "Broken expires header %s", exp);
 +reason = apr_psprintf(p, "Broken expires header %s", exp);


Still not right - 'exp' is an apr_time_t, you mean 'exps' I guess?

mod_cache.c: In function `cache_in_filter':
mod_cache.c:543: warning: format argument is not a pointer (arg 3)




Oooh, yowtch... good call.  I wasn't even looking at that part.

--Cliff





--
Paul J. Reder
---
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it.  Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein

RE: cvs commit: httpd-2.0/modules/experimental mod_cache.c

[Bill Stoddard]

Thanks! Fixing in 2.0 and 2.1...

Bill
> 
> On Tue, Dec 17, 2002 at 05:10:05PM -, Bill Stoddard wrote:
> >   Fix PR 15113, a core dump in cache_in_filter when
> >   a redirect occurs. The code was passing a format string and
> >   integer to apr_pstrcat. Changed to apr_psprintf. [Paul J. Reder]
> >   
> >   PR: 15113
> ...
> >else if (exps != NULL && exp == APR_DATE_BAD) {
> >/* if a broken Expires header is present, don't cache it */
> >   -reason = apr_pstrcat(p, "Broken expires header %s", exp);
> >   +reason = apr_psprintf(p, "Broken expires header %s", exp);
> 
> Still not right - 'exp' is an apr_time_t, you mean 'exps' I guess?
> 
> mod_cache.c: In function `cache_in_filter':
> mod_cache.c:543: warning: format argument is not a pointer (arg 3)

Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c

[Cliff Woolley]

On Tue, 17 Dec 2002, Joe Orton wrote:

> On Tue, Dec 17, 2002 at 05:10:05PM -, Bill Stoddard wrote:
> >else if (exps != NULL && exp == APR_DATE_BAD) {
> >/* if a broken Expires header is present, don't cache it */
> >   -reason = apr_pstrcat(p, "Broken expires header %s", exp);
> >   +reason = apr_psprintf(p, "Broken expires header %s", exp);
>
> Still not right - 'exp' is an apr_time_t, you mean 'exps' I guess?
>
> mod_cache.c: In function `cache_in_filter':
> mod_cache.c:543: warning: format argument is not a pointer (arg 3)


Oooh, yowtch... good call.  I wasn't even looking at that part.

--Cliff

Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c

[Joe Orton]

On Tue, Dec 17, 2002 at 05:10:05PM -, Bill Stoddard wrote:
>   Fix PR 15113, a core dump in cache_in_filter when
>   a redirect occurs. The code was passing a format string and
>   integer to apr_pstrcat. Changed to apr_psprintf. [Paul J. Reder]
>   
>   PR: 15113
...
>else if (exps != NULL && exp == APR_DATE_BAD) {
>/* if a broken Expires header is present, don't cache it */
>   -reason = apr_pstrcat(p, "Broken expires header %s", exp);
>   +reason = apr_psprintf(p, "Broken expires header %s", exp);

Still not right - 'exp' is an apr_time_t, you mean 'exps' I guess?

mod_cache.c: In function `cache_in_filter':
mod_cache.c:543: warning: format argument is not a pointer (arg 3)

RE: Mod_auth_digest URI Mismatch

[Rob Emanuele]

Thanks.  I found that too.  Is this listed anywhere in Microsoft's
Knowledge Base?

Any suggestions for a workaround?

Praying for a hotfix,

Rob

-Original Message-
From: André Malo [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, December 17, 2002 10:26 AM
To: [EMAIL PROTECTED]
Subject: Re: Mod_auth_digest URI Mismatch


* Rob Emanuele wrote:

> When using IE 6.0.2600 or the WinInet API which uses IE to retrieve 
> data from a cgi that has params in the get request I get an error:
> 
> Digest: uri mismatch -  does not match 
> request-uri 
> 
> Is this a bug in the mod_auth_digest or in the way IE6 generates 
> responses to a digest challenge?

It's a bug in IE, see also the note at 


> If I look at the packets going across
> the wire the Autorization header definitely says 
> uri="/cgi%2Dbin/get_age.pl".

yes, that's the bug. The query string lacks.

nd
-- 
my @japh = (sub{q~Just~},sub{q~Another~},sub{q~Perl~},sub{q~Hacker~});
my $japh = q[sub japh { }]; print join   #
 [ $japh =~ /{(.)}/] -> [0] => map $_ -> ()  #André Malo #
=> @japh;# http://www.perlig.de/ #

RE: Memory leak on Windows [Bugzilla #11427]

[Bill Stoddard]

I am running 2.0.44-dev (latest snapshot in CVS from just a few minutes ago) and
I'm not able to recreate this problem. Have you tried the latest version of 2.0
(CVS HEAD)?  Just for fun, try disabling keep-alive connections or set
MaxKeepAliveRequests to a small value (maybe from the default of 100 to 10) and
report back the results.

Bill

>
> Hi,
>
> I'm still trying to track the cause of this problem down, and I'm hoping
> somebody around here can help me.
>
> To summarize, I'm seeing Apache's memory footprint grow abnormally large
> on Windows when using CGIs.  The size of the growth seems to be
> proportional to the amount of data printed to stdout from the CGI.
>
> Some sample data:
>  - With 16 threads and 1 meg sent to stdout, combined physical and virtual
>memory reaches about 70 megs after hammering the server for several
>minutes
>  - If I increase the amount of stdout data to 2 megs, the process grows to
>about 130 megs within another few minutes.
>
> I've spent the last few days reviewing the code, and I'm a bit confused
> about the mpm_winnt pool cleanup code.  I haven't spent a lot of time
> reading the code in the past, so there's a good chance that I've just
> missed something.  As far as I can tell, ap_read_request() creates the
> request pool, but nothing explicitly cleans it up.  Instead, it looks like
> mpm_recycle_completion_context() clears the ptrans pool the next time the
> thread handles a request.  While this seems funny to me, I don't see why
> some of the memory would fail to be released.
>
> I've tried to simplify my httpd.conf file to reduce the test case:
>
>   ServerRoot c:/varju/webct/webct/server
>   ThreadsPerChild 16
>   LoadModule cgi_module modules/mod_cgi.so
>   LoadModule alias_module modules/mod_alias.so
>   Listen 80
>   ScriptAlias /test.pl c:/varju/webct/webct/webct/generic/public/test.pl
>
> Can anybody offer me suggestions of where to look next?
>
> Thanks,
> Alex.

Re: Memory leak on Windows [Bugzilla #11427]

[Alex Varju]

Hi,

I'm still trying to track the cause of this problem down, and I'm hoping
somebody around here can help me.

To summarize, I'm seeing Apache's memory footprint grow abnormally large
on Windows when using CGIs.  The size of the growth seems to be
proportional to the amount of data printed to stdout from the CGI.

Some sample data:
 - With 16 threads and 1 meg sent to stdout, combined physical and virtual
   memory reaches about 70 megs after hammering the server for several
   minutes
 - If I increase the amount of stdout data to 2 megs, the process grows to
   about 130 megs within another few minutes.

I've spent the last few days reviewing the code, and I'm a bit confused
about the mpm_winnt pool cleanup code.  I haven't spent a lot of time
reading the code in the past, so there's a good chance that I've just
missed something.  As far as I can tell, ap_read_request() creates the
request pool, but nothing explicitly cleans it up.  Instead, it looks like
mpm_recycle_completion_context() clears the ptrans pool the next time the
thread handles a request.  While this seems funny to me, I don't see why
some of the memory would fail to be released.

I've tried to simplify my httpd.conf file to reduce the test case:

  ServerRoot c:/varju/webct/webct/server
  ThreadsPerChild 16
  LoadModule cgi_module modules/mod_cgi.so
  LoadModule alias_module modules/mod_alias.so
  Listen 80
  ScriptAlias /test.pl c:/varju/webct/webct/webct/generic/public/test.pl

Can anybody offer me suggestions of where to look next?

Thanks,
Alex.

Re: Mod_auth_digest URI Mismatch

[André Malo]

* Rob Emanuele wrote:

> When using IE 6.0.2600 or the WinInet API which uses IE to retrieve data
> from a cgi that has params in the get request I get an error:
> 
> Digest: uri mismatch -  does not match
> request-uri 
> 
> Is this a bug in the mod_auth_digest or in the way IE6 generates
> responses to a digest challenge?

It's a bug in IE, see also the note at 


> If I look at the packets going across
> the wire the Autorization header definitely says
> uri="/cgi%2Dbin/get_age.pl".

yes, that's the bug. The query string lacks.

nd
-- 
my @japh = (sub{q~Just~},sub{q~Another~},sub{q~Perl~},sub{q~Hacker~});
my $japh = q[sub japh { }]; print join   #
 [ $japh =~ /{(.)}/] -> [0] => map $_ -> ()  #André Malo #
=> @japh;# http://www.perlig.de/ #

Mod_auth_digest URI Mismatch

[Rob Emanuele]

Using Apache 2.0.40... On RH8.0

When using IE 6.0.2600 or the WinInet API which uses IE to retrieve data
from a cgi that has params in the get request I get an error:

Digest: uri mismatch -  does not match
request-uri 

Is this a bug in the mod_auth_digest or in the way IE6 generates
responses to a digest challenge?  If I look at the packets going across
the wire the Autorization header definitely says
uri="/cgi%2Dbin/get_age.pl".

Thanks,

Rob

[PATCH] mod_cache - lazy initialization port to 2.0

[Bill Stoddard]

Vote in STATUS: mod_cache lazy initialization

This patch eliminates sconf and scache variables and defers initialization of
conf,
cache and cc_out till they are needed. Saves a few cycles for responses that
cannot
be cached.

I am interested in porting this to 2.0 just to keep mod_cache insync with 2.1

Bill

Index: mod_cache.c
===
RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_cache.c,v
retrieving revision 1.64.2.2
diff -u -r1.64.2.2 mod_cache.c
--- mod_cache.c 17 Dec 2002 17:10:05 -  1.64.2.2
+++ mod_cache.c 17 Dec 2002 17:46:33 -
@@ -418,23 +418,16 @@
 {
 int rv;
 request_rec *r = f->r;
+cache_request_rec *cache;
+cache_server_conf *conf;
 char *url = r->unparsed_uri;
-const char *cc_out = apr_table_get(r->headers_out, "Cache-Control");
+const char *cc_out;
 const char *exps, *lastmods, *dates, *etag;
 apr_time_t exp, date, lastmod, now;
 apr_off_t size;
 cache_info *info;
-void *sconf = r->server->module_config;
-cache_server_conf *conf =
-(cache_server_conf *) ap_get_module_config(sconf, &cache_module);
-void *scache = r->request_config;
-cache_request_rec *cache =
-(cache_request_rec *) ap_get_module_config(scache, &cache_module);
-apr_bucket *split_point = NULL;
-

-ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, f->r->server,
- "cache: running CACHE_IN filter");
+apr_bucket *split_point = NULL;

 /* check first whether running this filter has any point or not */
 if(r->no_cache) {
@@ -442,10 +435,11 @@
 return ap_pass_brigade(f->next, in);
 }

-/* make space for the per request config
- * We hit this code path when CACHE_IN has been installed by someone
- * other than the cache handler
- */
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r->server,
+ "cache: running CACHE_IN filter");
+
+/* Setup cache_request_rec */
+cache = (cache_request_rec *) ap_get_module_config(r->request_config,
&cache_module);
 if (!cache) {
 cache = apr_pcalloc(r->pool, sizeof(cache_request_rec));
 ap_set_module_config(r->request_config, &cache_module, cache);
@@ -516,8 +510,10 @@
 lastmod = APR_DATE_BAD;
 }

-/* read the etag from the entity */
+conf = (cache_server_conf *)
ap_get_module_config(r->server->module_config, &cache_module);
+/* read the etag and cache-control from the entity */
 etag = apr_table_get(r->headers_out, "Etag");
+cc_out = apr_table_get(r->headers_out, "Cache-Control");

 /*
  * what responses should we not cache?

Re: [Review] MPM docs revision

[Brad Nicholes]

Oops, forgot about the third parameter on SecureListen.  The third parameter indicates 
wheither mutual authenication should be used.  If mutual authentication is wanted, the 
third parameter should be set to "MUTUAL", but in reality any value as the third 
parameter will enable mutual authentication.



Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

>>> [EMAIL PROTECTED] Tuesday, December 17, 2002 10:06:14 AM >>>
* Brad Nicholes wrote:

>>- mpm_netware:
>>  * MaxThreads - there was a limit of 250 documented. hmm, I couldn't
> find
>>   *any* reference to a value of 250, so I took the obvious from
>>mpm_netware: MaxThreads 2048 (as maximum and default)
> 
> The default for MaxThreads in the configuration file is 250.  If
> omitted it will default to the HARD_THREAD_LIMIT of 2048.  Which one of
> the defaults is appropriate for the documentation?

the value, if the directive is omitted.
(but we could consider to change the default in mpm_netware.c, if 2048 is 
too high in almost all cases (i.e. as a *default* value) and 250 is 
recommended.)

> The NetWare SecureListen directive, at the very least, should be added
> to the Novell NetWare Platform Specific Notes (platform/netware.html).
> There is a section on that page for Additional NetWare specific
> directives.

ah, hmm. CGIMapExtension is currently listed there, but documented in core.

I see some ways to handle it:

- put arch-specific directives into core.xml (CGIMapExtension, 
SecureListen, ScriptInterpreterSource, BS2000Account).

- introduce docs for the architecture modules (mod_win32, mod_netware, 
mod_nw_ssl). BS2000Account would be kept in mpm_common that way (or core?).

- put all arch specific the stuff to the mpm docs

I think, I'd prefer the second.

The directive is implemented through the built in module
> MOD_NW_SSL which is also NetWare specific.  I'm not sure if there should
> be an additional module documentation page for this module or not.  This
> is the module that implements SSL functionality for the NetWare platform
> and replaces the need to use MOD_SSL on NetWare.  The SecureListen
> directive takes an " | " and the name of a
> certificate.

there's a third, optional parameter. What does it do?

> If you want to add this directive to the NetWare doc, I can fill in the
> details later.

ok, when we've puzzled out the above.

nd
-- 
print "Just Another Perl Hacker";

# André Malo,  #

Re: [Review] MPM docs revision

[André Malo]

* Brad Nicholes wrote:

>>- mpm_netware:
>>  * MaxThreads - there was a limit of 250 documented. hmm, I couldn't
> find
>>   *any* reference to a value of 250, so I took the obvious from
>>mpm_netware: MaxThreads 2048 (as maximum and default)
> 
> The default for MaxThreads in the configuration file is 250.  If
> omitted it will default to the HARD_THREAD_LIMIT of 2048.  Which one of
> the defaults is appropriate for the documentation?

the value, if the directive is omitted.
(but we could consider to change the default in mpm_netware.c, if 2048 is 
too high in almost all cases (i.e. as a *default* value) and 250 is 
recommended.)

> The NetWare SecureListen directive, at the very least, should be added
> to the Novell NetWare Platform Specific Notes (platform/netware.html).
> There is a section on that page for Additional NetWare specific
> directives.

ah, hmm. CGIMapExtension is currently listed there, but documented in core.

I see some ways to handle it:

- put arch-specific directives into core.xml (CGIMapExtension, 
SecureListen, ScriptInterpreterSource, BS2000Account).

- introduce docs for the architecture modules (mod_win32, mod_netware, 
mod_nw_ssl). BS2000Account would be kept in mpm_common that way (or core?).

- put all arch specific the stuff to the mpm docs

I think, I'd prefer the second.

The directive is implemented through the built in module
> MOD_NW_SSL which is also NetWare specific.  I'm not sure if there should
> be an additional module documentation page for this module or not.  This
> is the module that implements SSL functionality for the NetWare platform
> and replaces the need to use MOD_SSL on NetWare.  The SecureListen
> directive takes an " | " and the name of a
> certificate.

there's a third, optional parameter. What does it do?

> If you want to add this directive to the NetWare doc, I can fill in the
> details later.

ok, when we've puzzled out the above.

nd
-- 
print "Just Another Perl Hacker";

# André Malo,  #

RE: cvs commit: httpd-2.0/modules/experimental mod_cache.c

[Bill Stoddard]

Nice catch Paul.

Bill

> rederpj 2002/12/17 07:29:02
> 
>   Modified:.CHANGES
>modules/experimental mod_cache.c
>   Log:
>   mod_cache: Fix PR 15113, a core dump in cache_in_filter when
>   a redirect occurs. The code was passing a format string and
>   integer to apr_pstrcat. Changed to apr_psprintf. [Paul J. Reder]
>   
>   Revision  ChangesPath
>   1.1012+5 -0  httpd-2.0/CHANGES
>   
>   Index: CHANGES
>   ===
>   RCS file: /home/cvs/httpd-2.0/CHANGES,v
>   retrieving revision 1.1011
>   retrieving revision 1.1012
>   diff -u -r1.1011 -r1.1012
>   --- CHANGES 15 Dec 2002 16:37:18 -  1.1011
>   +++ CHANGES 17 Dec 2002 15:29:01 -  1.1012
>   @@ -2,6 +2,11 @@
>
>  [Remove entries to the current 2.0 section below, when backported]
>
>   +  *) mod_cache: Fix PR 15113, a core dump in cache_in_filter when
>   + a redirect occurs. The code was passing a format string and
>   + integer to apr_pstrcat. Changed to apr_psprintf.
>   + [Paul J. Reder]
>   +
>  *) mod_mime: Workaround to prevent a segfault if r->filename=NULL
> [Brian Pane]
> 
>   
>   
>   
>   1.70  +2 -2  httpd-2.0/modules/experimental/mod_cache.c
>   
>   Index: mod_cache.c
>   ===
>   RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_cache.c,v
>   retrieving revision 1.69
>   retrieving revision 1.70
>   diff -u -r1.69 -r1.70
>   --- mod_cache.c 11 Dec 2002 22:31:28 -  1.69
>   +++ mod_cache.c 17 Dec 2002 15:29:02 -  1.70
>   @@ -532,11 +532,11 @@
> * We include 304 Not Modified here too as this is the 
> origin server
> * telling us to serve the cached copy.
> */
>   -  reason = apr_pstrcat(p, "Response status %d", r->status);
>   +  reason = apr_psprintf(p, "Response status %d", r->status);
>} 
>else if (exps != NULL && exp == APR_DATE_BAD) {
>/* if a broken Expires header is present, don't cache it */
>   -reason = apr_pstrcat(p, "Broken expires header %s", exp);
>   +reason = apr_psprintf(p, "Broken expires header %s", exp);
>}
>else if (r->args && exps == NULL) {
>/* if query string present but no expiration time, 
> don't cache it
>   
>   
>   

Re: [Review] MPM docs revision

[Brad Nicholes]

>- mpm_netware:
>  * MaxThreads - there was a limit of 250 documented. hmm, I couldn't
find 
>   *any* reference to a value of 250, so I took the obvious from 
>mpm_netware: MaxThreads 2048 (as maximum and default)

The default for MaxThreads in the configuration file is 250.  If
omitted it will default to the HARD_THREAD_LIMIT of 2048.  Which one of
the defaults is appropriate for the documentation?

The NetWare SecureListen directive, at the very least, should be added
to the Novell NetWare Platform Specific Notes (platform/netware.html). 
There is a section on that page for Additional NetWare specific
directives.  The directive is implemented through the built in module
MOD_NW_SSL which is also NetWare specific.  I'm not sure if there should
be an additional module documentation page for this module or not.  This
is the module that implements SSL functionality for the NetWare platform
and replaces the need to use MOD_SSL on NetWare.  The SecureListen
directive takes an " | " and the name of a
certificate.  The default in the configuration file is 

SecureListen 443 "SSL CertificateDNS"

If you want to add this directive to the NetWare doc, I can fill in the
details later.

Brad


Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

>>> [EMAIL PROTECTED] Monday, December 16, 2002 7:09:58 PM >>>
[xpost dev & docs]

the MPM documentation is currently incomplete and partially outdated.
I've tried to remove this flaw... ;-)

the patch against the existing source files (xml) can be found at 
 (~ 68K). If you want to read it
as 
HTML, try  as a starting
point.

However, here's a summary of the main changes:

- added new docs for beos, leader, mpmt_os2 and threadpool.
  The descriptions are mainly taken from the READMEs and/or code
comments.
- mpm_common:
  * fixed the s in mpm_common
  * moved AcceptMutex to mpm_common;
document the mutex mechanism "posixsem"
  * added BS2000Account to mpm_common
(I'm not sure, whether it should appear here or elsewhere. It
*seems* 
to be supported only by prefork and perchild (if perchild would
work). 
The description is obtained from the 1.3 docs.
  * fixed several default values
  * moved MaxThreadsPerChild and NumServers out to perchild
(btw: we could consider to rename NumServers to StartServers...)
  * rearranged some stuff and added several comments, that I found
useful 
;-)
- mpm_netware:
  * MaxThreads - there was a limit of 250 documented. hmm, I couldn't
find 
*any* reference to a value of 250, so I took the obvious from 
mpm_netware: MaxThreads 2048 (as maximum and default)
- perchild:
  * extended the explanations about using different user ids. Hope,
that's 
correct.
  * extended and adjusted the directive descriptions
(remember, NumServers and MaxThreadsPerChild moved in)
- prefork:
  * moved AcceptMutex to mpm_common (as stated already above)

Please note again, that these are only the main changes.

There is still one directive (except GProfDir ;-) that's not
documented:
SecureListen, which comes with the netware ssl module. I didn't add it,

because I'm a bit unsure, where to place it. any ideas?


Probably more interesting for the doccos: the growing up of the MPM
section 
caused some style changes for better navigation etc. A diff against the

style files can be found at  (~
17K).

Here are the main changes:

- reintroduced the sidebar for the module index page (obvious ;-)
  * didn't want to leave the section links so alone, thus added some
s.
- changed the ordering of the core/MPMs as follows:
  * core
  * mpm_common
  * alphabetical list of the mpms (ordered by their "natural" names).
- same appeared on the sitemap 
  ()
- changed  headings of the modulesynopsis files, so that they match
the 
  titles in the sitemap. This should better reflect the nature of the 
  modules. (affects only core & MPMs)

nd
-- 
s  s^saoaaaoaaoaaaom  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 ms;s;\s;s;g;y;s;:;s;y#mailto: #
 \51/\134\137| http://www.perlig.de #;print;# > [EMAIL PROTECTED]

Re: [Review] MPM docs revision

[Erik Abele]

> Von: Enrico Weigelt <[EMAIL PROTECTED]>
> Antworten an: [EMAIL PROTECTED]
> Datum: Tue, 17 Dec 2002 06:30:55 +0100
> An: [EMAIL PROTECTED]
> Betreff: Re: [Review] MPM docs revision
> 
> On Tue, Dec 17, 2002 at 03:09:58AM +0100, André Malo wrote:
> 
> 
> 
>> - added new docs for beos, leader, mpmt_os2 and threadpool.
>> The descriptions are mainly taken from the READMEs and/or code comments.
> 
> i'll post some stuff about my new mpm in some days ...
> 
> btw: are there manpages for the apache configuration ?
> 

We removed the available manpages for apachectl & httpd since there is
nobody who is able to maintain and update the nroff stuff (see
http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/man/)

You can find the updated XML/HTML versions online at
http://httpd.apache.org/docs-2.0/programs/httpd.html
and http://httpd.apache.org/docs-2.0/programs/apachectl.html

HTH,
erik

Re: mod_deflate thread safe ?

[Henri Gomez]

Henri Gomez wrote:

Brian Pane wrote:


Henri Gomez wrote:


I played with mod_deflate with Apache 2.0.39 on one of
my iSeries and got Apache exit due to Thread Errors.

Did there is known problem with deflate present in 2.0.39,
which has been solved in 2.0.43 and later ?



Hum, it may be related to mod_jk/mod_deflate.

Here is was I got from my iSeries logs :


The problem was certainly due to mod_jk build on my iSeries
which was done WITHOUT defining _REENTRANT and so wasn't
thread safe.

BTW, JK 1.2.2 is just released.

Re: [Review] MPM docs revision

[Enrico Weigelt]

On Tue, Dec 17, 2002 at 03:09:58AM +0100, André Malo wrote:



> - added new docs for beos, leader, mpmt_os2 and threadpool.
>   The descriptions are mainly taken from the READMEs and/or code comments.

i'll post some stuff about my new mpm in some days ...

btw: are there manpages for the apache configuration ?

~-n
-- 
-
 Enrico Weigelt==   metux ITS 
 Webhosting ab 5 EUR/Monat.  UUCP, rawIP und vieles mehr.

 phone: +49 36207 519931 www:   http://www.metux.de/ 
 fax:   +49 36207 519932 email: [EMAIL PROTECTED]
 cellphone: +49 174 7066481  smsgate:   [EMAIL PROTECTED]
-
 Diese Mail wurde mit UUCP versandt.  http://www.metux.de/uucp/

Re: mod_deflate thread safe ?

[Henri Gomez]

Brian Pane wrote:

Henri Gomez wrote:


I played with mod_deflate with Apache 2.0.39 on one of
my iSeries and got Apache exit due to Thread Errors.

Did there is known problem with deflate present in 2.0.39,
which has been solved in 2.0.43 and later ?


Hum, it may be related to mod_jk/mod_deflate.

Here is was I got from my iSeries logs :

User Trace Dump for job 810710/QTMHHTTP/APACHEDFT. Size: 300K, Wrapped 1 
times.
--- 12/16/2002 11:53:29 --- 

00E3:406904 Stack:  QSYS   / QP0ZCPA QP0ZUDBG477 
: Qp0zDumpStack
00E3:406928 Stack:  QSYS   / QP0ZSCPAQP0ZSCPA1682 
: Qp0zSUDumpStack
00E3:406944 Stack:  QSYS   / QP0ZSCPAQP0ZSCPA1693 
: Qp0zSUDumpTargetStack
00E3:406944 Stack:  Completed 

--- 12/16/2002 11:53:35 --- 

 00E0:158016 C5275D984C:003720 L:00D0 mpmt_pthread.c:Exception 
handler threads communications area
00E0:158536 Stack Dump For Current Thread 

00E0:158536 Stack:  mpmt_pthread.c:request thread exception 

00E0:158624 Stack:  Library/ Program Module  Stmt 
Procedure
00E0:158656 Stack:  QSYS   / QLESPI  QLECRTTH1112  : 
LE_Create_Thread2__FP12crtth_parm_t
00E0:158672 Stack:  QSYS   / QP0WPINTQP0WSPTHR   2459  : 
pthread_create_part2
00E0:158696 Stack:  QHTTPSVR   / QZSRAPR THREAD  2 : 
dummy_worker
00E0:158712 Stack:  QHTTPSVR   / QZSRCOREMPMT_PTHRE  16: 
request_thread
00E0:158728 Stack:  QHTTPSVR   / QZSRCOREHTTP_ASYNC  25: 
ap_process_IOCP
00E0:163824 Stack:  QHTTPSVR   / QZSRCOREHTTP_REQUE  19: 
ap_process_request
00E0:163848 Stack:  QHTTPSVR   / QZSRCOREHTTP_CONFI  20: 
ap_invoke_handler
00E0:163856 Stack:  QHTTPSVR   / QZSRCOREHTTP_CONFI  5 : 
ap_run_handler
00E0:163880 Stack:  QHTTPSVR   / MOD_JK  MOD_JK  48: 
jk_handler
00E0:171096 Stack:  QSYS   / QMHPDEH 282   : 

00E0:171120 Stack:  QHTTPSVR   / QZSRCOREMPMT_PTHRE  1 : 
Request_Thread_Excp_Handler
00E0:171136 Stack:  QHTTPSVR   / QZSRCOREMPMT_PTHRE  18: 
Common_Thread_Excp_Handler_Code
00E0:171152 Stack:  QHTTPSVR   / QZSRAPR OS400TRACE  1 : 
apr_dstack
00E0:171176 Stack:  QSYS   / QP0ZCPA QP0ZUDBG477   : 
Qp0zDumpStack

I'll forward it to my correspondant in IBM Rochester Labs for study :)