date:20020102

Re: building with SSL

2002-01-02 Thread Jeff Trawick


Dwayne Miller <[EMAIL PROTECTED]> writes:

> Where are the instructions for compiling Apache 2.0 with mod_ssl support?

./configure --help | grep -i ssl

First try --enable-ssl.  If it can't find OpenSSL, or the OpenSSL
found in the normal search order is old, use --with-ssl to point to an
up-to-date installation.

-- 
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
   http://www.geocities.com/SiliconValley/Park/9289/
 Born in Roswell... married an alien...

[STATUS] (httpd-2.0) Wed Jan 2 23:45:06 EST 2002

2002-01-02 Thread Rodent of Unusual Size


APACHE 2.0 STATUS:  -*-text-*-
Last modified at [$Date: 2002/01/02 19:34:47 $]

Release:

2.0.30  : In development
2.0.29  : tagged November 27, 2001
2.0.28  : released November 13, 2001
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

RELEASE SHOWSTOPPERS:

* ap_directory_walk skips some per-dir config merge functions
  if there is no "" block in the configuration
Message-ID: <[EMAIL PROTECTED]>

* Test suite failures:
  o perchild doesn't even build
  o worker is also failing some of the 'cgi' subtests
  (see http://Source-Zone.Org/Apache/regression/>):

* If any request gets to the core handler, without a flag that this 
  r->filename was tested by dir/file_walk, we need to 500 at the very 
  end of the ap_process_request_internal() processing.  This provides
  authors of older modules better compatibility, while still improving
  the security and robustness of 2.0. 
Status: still need to decide where this goes, OtherBill comments...
Message-ID: <065701c14526$495203b0$[EMAIL PROTECTED]>
we need to look at halting this in the 'default handler' case,
and that implies pushing the 'handler election' into the request
internal processing phase from the run request phase.

* There is a bug in how we sort some hooks, at least the pre-config
  hook.  The first time we call the hooks, they are in the correct 
  order, but the second time, we don't sort them correctly.  Currently,
  the modules/http/config.m4 file has been renamed to 
  modules/http/config2.m4 to work around this problem, it should moved
  back when this is fixed.rbb

* The Add...Filter and Set...Filter directives do not allow the
  administrator to order filters, beyond the order of filename (mime)
  extensions.  It isn't clear if Set...Filter(s) should be inserted 
  before or after the Add...Filter(s) which are ordered by sequence of
  filename extensions.  At minimum, some sort of +-[0-10] syntax seems
  like the quickest fix for a 2.0 gold release.

* mod_negotiation needs a new option or directive, something like
  ForceLanguagePriority, to fall back to the LanguagePriority
  directive instead of returning a "no acceptable variant" error.
Status: Bill has some code in his tree that accomplishes
this, and will commit it Friday after it's tested.

* Fold mod_auth_db features back into mod_auth_dbm, and depricate it.
This can't wait until we have a 2.0-gold release, if folks need
to move over to auth_dbm, we can't do that to them after 2.0 gold.
  Status: Ian says.. auth_dbm can now handle multiple DBM types,
  is this still an issue?
  Vote: Remove mod_auth_db
+1: Justin

* Convert all instances of the old apr_lock_t type to the new
  types (once they are fully supported in APR).
Status: Aaron is working on converting INTRAPROCESS
to apr_thread_mutex_t types. Full replacements for
LOCKALL and CROSS_PROCESS are not yet complete on all
platforms, and should only be used in MPMs like worker
with limited OS exposure.

* ap_create_scoreboard() can exit the process, leaving stuff like
  mod_cgid's daemon process stranded.  Either ap_create_scoreboard()
  needs to be called at a different time or the pre-mpm hook needs
  to be able to return an error code.

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

* Handling of %2f in URIs.  Currently both 1.3 and 2.0
  completely disallow %2f in the request URI path (see
  ap_unescape_url() in util.c).  It's permitted and passed
  through in the query string, however.  Roy says the
  original reason for disallowing it, from five years ago,
  was to protect CGI scripts that applied PATH_INFO to
  a filesystem location and which might be t

[STATUS] (apache-1.3) Wed Jan 2 23:45:04 EST 2002

2002-01-02 Thread Rodent of Unusual Size


APACHE 1.3 STATUS:  -*-text-*-
  Last modified at [$Date: 2001/12/18 15:31:57 $]

Release:


   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  : In alpha development, see httpd-2.0 repository

RELEASE SHOWSTOPPERS:



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

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

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

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

* long pathnames with many components and no AllowOverride None
  Workaround is to define  with AllowOverride None,
  which is something all sites should do in any case.
Status: Marc was looking at it.

* Ronald Tschalär's patch to mod_proxy to allow other modules to
  set headers too (needed by mod_auth_digest)
Message-ID: <[EMAIL PROTECTED]>
Status:


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

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

* Patch from "C. Bottelier" <[EMAIL PROTECTED]> to run
Apache without daemonizing the parent process. PR#7040
Status: fanf +1 (except it needs docs)

* Andrew Ford's patch (1999/12/05) to add absolute times to mod_expires
Message-ID: <[EMAIL PROTECTED]>
Status: Martin +1, Jim +1, Ken +1 (on concept)

* Raymond S Brand's path to mod_autoindex to fix the header/readme
  include processing so the envariables are correct for the included
  documents.  (Actually, there are two variants in the patch message,
  for two different ways of doing it.)
Message-ID: <[EMAIL PROTECTED]>
Status: Martin +1(concept)

* Jayaram's patch (10/27/99) for changes to mod_autoindex
 
Problem 1:

AddIcon (,) ^^DIRECTORY^^ 
and 
AddIcon (,) ^^BLANKICON^^ 
should be able to set the alternate text and icon file for any
directory/blankicon in a directory listing. This was not happening
because the alternate text for ^^DIRECTORY^^ and ^^BLANKICON^^ were
hardcoded to  "DIR" and "   " respectively.
  Status: resolved in Apache 2.0

Problem 2:
-
IndexIgnore  should hide the files with this file-
extension in directory listings. This was NOT happening because the 
total filename was being compared with the file-extension.

Status: Martin +1(untested), Ken +1(untested)
   
* Salvador Ortiz Garcia <[EMAIL PROTECTED]>' patch to allow DirectoryIndex
  to refer to URIs for non-static resources.
MID: <[EMAIL PROTECTED]>
Stat

Re: cvs commit: httpd-2.0/server core.c

2002-01-02 Thread William A. Rowe, Jr.


From: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Wednesday, January 02, 2002 8:25 PM


> > BTW --- 1.3.23 question here; The API_EXPORT -> API_EXPORT_NONSTD changes in
> > theory require an MMN bump on Win32.  Which really sucks, because I don't want
> > to break everyone else.  Anyone given any thought as to how we can avoid an MMN
> > bump, when all that's happened is a specific platform has been broken [linkage,
> > etc?]  It almost makes me think we _aught_ to drop the .def file for win32,
> > creating decorated symbol names that now-broken modules will refuse to link
> > against, sparing all other platforms a version bump.
> 
> I -think- we can ditch the .def file. I'm a bit concerned that we might break 
>something
> unexpected...  Also need to bump the MMN_MAJOR. Doing anything else is a kludge that 
>could
> introduce more problems than it solves.

I believe that this will destroy binary compatibility.  Ergo - no bump.  There is no
API change or structure change in 1.3.23 that harms compilation, or precompiled .so's
on other platforms.  Win32 was the only 'victim' of the cdecl/nonstd changes.

Since changing the ApacheCore.dll wipes out binary compatibility, in and of itself,
there should be no reason to bump the MMN.  1.3.22 and prior modules simply won't
load, and simply won't suffer from segfault-ish behavior.  It's all or nothing if
we destroy the .def, but we don't create headaches for the other platforms.  That's
the reason I suggested it.

Bill

Re: cvs commit: httpd-2.0/server core.c

2002-01-02 Thread Bill Stoddard



> From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
> Sent: Wednesday, January 02, 2002 4:56 PM
>
>
> > On Wed, Jan 02, 2002 at 04:46:01PM -0600, William A. Rowe, Jr. wrote:
> > > Broke more than proxy, without a rebuild all.  Time for an MMN bump, it seems :)
> >
> > I was wondering about that.  =)  What are the rules for a MMN bump?
>
> You break it, you bump it :)
>
> Seriously, whenever;
>
>   1. function declaration or return types change [broken binary compatibility.]
>
>   2. external structure members change [broken binary compatibility.]
>
> So when you changed the structs - you needed an MMN bump.

If you add an API or (more controversial) add a new field to the -end- of an existing
structure, you bump the MODULE_MAGIC_NUMBER_MINOR.

If you change an existing API, add a new field to a structure somewhere other then the
end, or modify an existing structure member, you bump the MODULE_MAGIC_NUMBER_MAJOR.

Modules compiled against earlier releases of Apache are binary compatabile with all
subsequent release of Apache IFF the MMN_MAJOR does not change. Bumping MMN_MAJOR 
breaks
binary compatability with all modules compiled against earlier releases of Apache.
>
> BTW --- 1.3.23 question here; The API_EXPORT -> API_EXPORT_NONSTD changes in
> theory require an MMN bump on Win32.  Which really sucks, because I don't want
> to break everyone else.  Anyone given any thought as to how we can avoid an MMN
> bump, when all that's happened is a specific platform has been broken [linkage,
> etc?]  It almost makes me think we _aught_ to drop the .def file for win32,
> creating decorated symbol names that now-broken modules will refuse to link
> against, sparing all other platforms a version bump.

I -think- we can ditch the .def file. I'm a bit concerned that we might break something
unexpected...  Also need to bump the MMN_MAJOR. Doing anything else is a kludge that 
could
introduce more problems than it solves.

Bill

Re: cvs commit: httpd-2.0/server core.c

2002-01-02 Thread William A. Rowe, Jr.

From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
Sent: Wednesday, January 02, 2002 4:56 PM

> On Wed, Jan 02, 2002 at 04:46:01PM -0600, William A. Rowe, Jr. wrote:
> > Broke more than proxy, without a rebuild all.  Time for an MMN bump, it seems :)
> 
> I was wondering about that.  =)  What are the rules for a MMN bump?

You break it, you bump it :)

Seriously, whenever;

  1. function declaration or return types change [broken binary compatibility.]

  2. external structure members change [broken binary compatibility.]

So when you changed the structs - you needed an MMN bump.

BTW --- 1.3.23 question here; The API_EXPORT -> API_EXPORT_NONSTD changes in
theory require an MMN bump on Win32.  Which really sucks, because I don't want
to break everyone else.  Anyone given any thought as to how we can avoid an MMN
bump, when all that's happened is a specific platform has been broken [linkage,
etc?]  It almost makes me think we _aught_ to drop the .def file for win32, 
creating decorated symbol names that now-broken modules will refuse to link 
against, sparing all other platforms a version bump.

Bill

Re: Directory completion?

2002-01-02 Thread Ryan Morgan

On Wed, Jan 02, 2002 at 04:18:30PM -0600, Austin Gonyou wrote:
> I'm really confused about Galeon. It seems that when I go to:
> http://digitalroadkill.net:8080/Galleries/
> 
> Galeon reports that:
> 'The PHP Filter did not receive suitable input data'
> 
> Does anyone know why I *might* receive this in one browser and not in
> another? When I telnet to port 8080 and request /Galleries/ it works
> like a champ. What am I missing?
>

This error happens when PHP sees a brigade that does not start with a 
file bucket.  

This can happen when ap_internal_redirect is called, (which it probably is
in your situation from mod_negotiation) which will send a seperate brigade 
with a single eos if an eos has not already been sent.

I have run across this problem in the past, and am not sure what the correct
solution is.  Should php send an eos when it is done generating data? 
If not, the php filter should check if the first bucket is an eos, and just
send it down the chain rather than sending the client an error message.

-Ryan

Re: cvs commit: httpd-2.0/server core.c

2002-01-02 Thread Justin Erenkrantz


On Wed, Jan 02, 2002 at 04:46:01PM -0600, William A. Rowe, Jr. wrote:
> Broke more than proxy, without a rebuild all.  Time for an MMN bump, it seems :)

I was wondering about that.  =)  What are the rules for a MMN bump?
-- justin

Re: cvs commit: httpd-2.0/server core.c

2002-01-02 Thread William A. Rowe, Jr.


From: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Wednesday, January 02, 2002 4:15 PM


> This patch breaks the proxy.  Specifically, anyone who uses 
>ap_proxy_make_fake_req().  Get
> a seg fault in ap_get_limit_req_body because r->per_dir_config is NULL.  I'll spend 
>some
> time on this tomorrow unless someone wants to jump on it tonight.

Broke more than proxy, without a rebuild all.  Time for an MMN bump, it seems :)

Bill

Re: Debugging help, please?

2002-01-02 Thread Bruce Korb

Thomas Eibner wrote:
> 
> On Wed, Jan 02, 2002 at 02:24:41PM -0800, Bruce Korb wrote:
> > I'll see what I can do tonight, when I get home.  Thanks.
> > I'm not really sure I've ever been able to capture a
> > child with gdb, though.  It's easy with UnixWare's Debug,
> > but I'll see what I can do.  Thanks! - Bruce
> 
> That's why you run apache in the single process mode (-X).

In that case, it won't work.  I need to be able to debug
my program:

  http://autogen.sourceforge.net

in the context of running as a CGI service.  I.e., spawned by
httpd.  Therefore, I first tried cloning the environment
by using a shell wrapper:

  #! /bin/sh
  exec 3> /tmp/test.sh
  env | sed "s,^\([a-zA-Z_]*\)=\(.*\),export \1='\2'" >&3
  cat > /tmp/test.data
  echo "autogen $@ < /tmp/test.data" >&3
  exec 3>&-
  autogen $@ < /tmp/test.data

That failed.  This succeeded:

  env - ksh /tmp/test.sh

leaving me quite baffled.  On Solaris and UnixWare,
just running the autogen binary directly works fine.
Only Linux.  The question I need to find an answer for
is, "why?"  :-(

Re: Directory completion?

2002-01-02 Thread Austin Gonyou

Ok. I found the source of the error. For some reason the default 404
server message isn't getting displayed and this other message is
instead. If I can find the bottom of it, I'll post with answers so it at
least goes into to archive. Thanks for those who've looked. 

Woops. I just figured it out. Since I've got a html ouput filter
redirecting to php to handle the output, when
error/HTTP_NOT_FOUND.html.var is called and it's trying to parse
top.html and bottom.html, it isn't. So, if I can get php to parse the
html correctly, then this message will go away. 

If you go to http://digitalroadkill.net:8080/as;dljfsad you'll see the
error message I'm talking about. This get's generated on every 404,
since PHP isn't parsing the html properly. 

Whew. I thought I was couldn't figure it out. I'm happy now thanks for
the time. 

On Wed, 2002-01-02 at 16:13, Austin Gonyou wrote:
> Ok..Sorry for the craziness. There seems to be something happening with
> Galeon. I tried links, again, and Mozilla and everything is working as
> it should. Thanks again for all the help. It even seems as though my
> filters are working correctly. 
> 
> On Wed, 2002-01-02 at 16:03, Austin Gonyou wrote:
> > Thanks for all the work. I just couldn't see that happening. I don't
> > care if it doesn't work for me, as long as it works for everyone else.
> 
> > 
> > Now I've got a more serious issue though. I can't even get /Galleries/
> > or / to parse php now it seems. I think my ouput filters are wrong. 
> > 
> > I used to be able to use the following:
> > 
> > 
> >   SetInputFilter php
> >   SetOutputFilter php
> >   
> > 
> > Now I have to use:
> > 
> > 
> >   SetInputFilter php
> >   SetOutputFilter php
> > 
> > 
> > and likewise with html. What am I doing wrong?
> > 
> > -- 
> > Austin Gonyou
> > Systems Architect, CCNA
> > Coremetrics, Inc.
> > Phone: 512-698-7250
> > email: [EMAIL PROTECTED]
> > 
> > "It is the part of a good shepherd to shear his flock, not to skin
> it."
> > Latin Proverb
> -- 
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-698-7250
> email: [EMAIL PROTECTED]
> 
> "It is the part of a good shepherd to shear his flock, not to skin it."
> Latin Proverb
-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-698-7250
email: [EMAIL PROTECTED]

"It is the part of a good shepherd to shear his flock, not to skin it."
Latin Proverb

signature.asc
Description: This is a digitally signed message part

Re: Debugging help, please?

2002-01-02 Thread Thomas Eibner


On Wed, Jan 02, 2002 at 02:24:41PM -0800, Bruce Korb wrote:
> I'll see what I can do tonight, when I get home.  Thanks.
> I'm not really sure I've ever been able to capture a 
> child with gdb, though.  It's easy with UnixWare's Debug,
> but I'll see what I can do.  Thanks! - Bruce

That's why you run apache in the single process mode (-X).

-- 
  Thomas Eibner  DnsZone 
  mod_pointer

Re: cvs commit: httpd-2.0/server core.c

2002-01-02 Thread William A. Rowe, Jr.

From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
Sent: Wednesday, January 02, 2002 4:15 PM

> On Wed, Jan 02, 2002 at 05:15:34PM -0500, Bill Stoddard wrote:
> > This patch breaks the proxy.  Specifically, anyone who uses 
>ap_proxy_make_fake_req().  Get
> > a seg fault in ap_get_limit_req_body because r->per_dir_config is NULL.  I'll 
>spend some
> > time on this tomorrow unless someone wants to jump on it tonight.
> 
> Is it valid for r->per_dir_config to be null?  Hmm.  I wonder if
> ap_get_limit_req_body should be fixed to handle this case instead
> of ap_http_filter?  -- justin

No.  It's entirely invalid.

At the very least - you are looking the r->server->lookup_defaults, plus the
 sections in per_dir_config.

That's always true, anything that changes that assumption is broken.  Now if
either proxy or your patch skips the initial  lookup (or it is 
otherwise circumvented) then you get what you pay for.

Bill

Re: Debugging help, please?

2002-01-02 Thread Bruce Korb

Thomas Eibner wrote:

> Try recompiling Apache with CFLAGS=-g and then start it in single
> child mode in gdb:
> 
> $ gdb /path/to/bin/httpd
> (gdb) run -X
> 
> .. does it help?

I'll see what I can do tonight, when I get home.  Thanks.
I'm not really sure I've ever been able to capture a 
child with gdb, though.  It's easy with UnixWare's Debug,
but I'll see what I can do.  Thanks! - Bruce

Re: Directory completion?

2002-01-02 Thread Austin Gonyou


I'm really confused about Galeon. It seems that when I go to:
http://digitalroadkill.net:8080/Galleries/

Galeon reports that:
'The PHP Filter did not receive suitable input data'

Does anyone know why I *might* receive this in one browser and not in
another? When I telnet to port 8080 and request /Galleries/ it works
like a champ. What am I missing?

(besides a few screws...)

On Wed, 2002-01-02 at 16:03, Austin Gonyou wrote:
> Thanks for all the work. I just couldn't see that happening. I don't
> care if it doesn't work for me, as long as it works for everyone else. 
> 
> Now I've got a more serious issue though. I can't even get /Galleries/
> or / to parse php now it seems. I think my ouput filters are wrong. 
> 
> I used to be able to use the following:
> 
> 
>   SetInputFilter php
>   SetOutputFilter php
>   
> 
> Now I have to use:
> 
> 
>   SetInputFilter php
>   SetOutputFilter php
> 
> 
> and likewise with html. What am I doing wrong?
> 
> -- 
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-698-7250
> email: [EMAIL PROTECTED]
> 
> "It is the part of a good shepherd to shear his flock, not to skin it."
> Latin Proverb
-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-698-7250
email: [EMAIL PROTECTED]

"It is the part of a good shepherd to shear his flock, not to skin it."
Latin Proverb



signature.asc
Description: This is a digitally signed message part

Re: Debugging help, please?

2002-01-02 Thread Thomas Eibner


On Wed, Jan 02, 2002 at 02:07:24PM -0800, Bruce Korb wrote:
> 
> Hi,
> 
> I'm trying to figure out how to use GDB or any debugger from within
> a cgi program started by Apache under Linux.  I tried the obvious:
> 
>   #! /bin/sh
>   DISPLAY=:0.0 xterm -e gdb /path/to/bin/exe
> 
> to no avail, so I was hoping for a hint here  :-).
> The more simplistic approach of cloning the environment in a shell
> script does not evidence the problem.  It only seems to be
> reproducible on Linux under Apache.  (It works correctly on other
> platforms or using different execution environments on Linux.)
> If this is a known problem with known workarounds or fixes,
> that would be even better than trying to use gdb  :-D

Try recompiling Apache with CFLAGS=-g and then start it in single
child mode in gdb:

$ gdb /path/to/bin/httpd
(gdb) run -X

.. does it help?

-- 
  Thomas Eibner  DnsZone 
  mod_pointer

Re: cvs commit: httpd-2.0/server core.c

2002-01-02 Thread Justin Erenkrantz

On Wed, Jan 02, 2002 at 05:15:34PM -0500, Bill Stoddard wrote:
> This patch breaks the proxy.  Specifically, anyone who uses 
>ap_proxy_make_fake_req().  Get
> a seg fault in ap_get_limit_req_body because r->per_dir_config is NULL.  I'll spend 
>some
> time on this tomorrow unless someone wants to jump on it tonight.

Is it valid for r->per_dir_config to be null?  Hmm.  I wonder if
ap_get_limit_req_body should be fixed to handle this case instead
of ap_http_filter?  -- justin

Re: cvs commit: httpd-2.0/server core.c

2002-01-02 Thread Bill Stoddard


This patch breaks the proxy.  Specifically, anyone who uses ap_proxy_make_fake_req().  
Get
a seg fault in ap_get_limit_req_body because r->per_dir_config is NULL.  I'll spend 
some
time on this tomorrow unless someone wants to jump on it tonight.

Bill

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 02, 2002 2:56 AM
Subject: cvs commit: httpd-2.0/server core.c


> jerenkrantz02/01/01 23:56:25
>
>   Modified:.CHANGES
>include  http_core.h
>modules/http http_protocol.c
>server   core.c
>   Log:
>   Fix LimitRequestBody directive by moving the relevant code from
>   ap_*_client_block to ap_http_filter (aka HTTP_IN).  This is the
>   only appropriate place for limit checking to occur (otherwise,
>   chunked input is not correctly limited).
>
>   Also changed the type of limit_req_body to apr_off_t to match the
>   other types inside of HTTP_IN.  Also made the strtol call for
>   limit_req_body a bit more robust.
>
>   Revision  ChangesPath
>   1.499 +4 -0  httpd-2.0/CHANGES
>
>   Index: CHANGES
>   ===
>   RCS file: /home/cvs/httpd-2.0/CHANGES,v
>   retrieving revision 1.498
>   retrieving revision 1.499
>   diff -u -r1.498 -r1.499
>   --- CHANGES 31 Dec 2001 21:03:12 - 1.498
>   +++ CHANGES 2 Jan 2002 07:56:24 - 1.499
>   @@ -1,4 +1,8 @@
>Changes with Apache 2.0.30-dev
>   +
>   +  *) Fix LimitRequestBody directive by placing it in the HTTP
>   + filter.  [Justin Erenkrantz]
>   +
>  *) Fix mod_proxy seg fault when the proxied server returns
> an HTTP/0.9 response or a bogus status line.
> [Adam Sussman]
>
>
>
>   1.58  +3 -3  httpd-2.0/include/http_core.h
>
>   Index: http_core.h
>   ===
>   RCS file: /home/cvs/httpd-2.0/include/http_core.h,v
>   retrieving revision 1.57
>   retrieving revision 1.58
>   diff -u -r1.57 -r1.58
>   --- http_core.h 1 Jan 2002 20:36:18 - 1.57
>   +++ http_core.h 2 Jan 2002 07:56:24 - 1.58
>   @@ -234,9 +234,9 @@
> * Return the limit on bytes in request msg body
> * @param r The current request
> * @return the maximum number of bytes in the request msg body
>   - * @deffunc unsigned long ap_get_limit_req_body(const request_rec *r)
>   + * @deffunc apr_off_t ap_get_limit_req_body(const request_rec *r)
> */
>   -AP_DECLARE(unsigned long) ap_get_limit_req_body(const request_rec *r);
>   +AP_DECLARE(apr_off_t) ap_get_limit_req_body(const request_rec *r);
>
>/**
> * Return the limit on bytes in XML request msg body
>   @@ -471,7 +471,7 @@
>#ifdef RLIMIT_NPROC
>struct rlimit *limit_nproc;
>#endif
>   -unsigned long limit_req_body;  /* limit on bytes in request msg body */
>   +apr_off_t limit_req_body;  /* limit on bytes in request msg body */
>long limit_xml_body;   /* limit on bytes in XML request msg body */
>
>/* logging options */
>
>
>
>   1.383 +33 -11httpd-2.0/modules/http/http_protocol.c
>
>   Index: http_protocol.c
>   ===
>   RCS file: /home/cvs/httpd-2.0/modules/http/http_protocol.c,v
>   retrieving revision 1.382
>   retrieving revision 1.383
>   diff -u -r1.382 -r1.383
>   --- http_protocol.c 6 Dec 2001 02:57:19 - 1.382
>   +++ http_protocol.c 2 Jan 2002 07:56:24 - 1.383
>   @@ -510,6 +510,8 @@
>
>typedef struct http_filter_ctx {
>apr_off_t remaining;
>   +apr_off_t limit;
>   +apr_off_t limit_used;
>enum {
>BODY_NONE,
>BODY_LENGTH,
>   @@ -536,6 +538,9 @@
>const char *tenc, *lenp;
>f->ctx = ctx = apr_palloc(f->r->pool, sizeof(*ctx));
>ctx->state = BODY_NONE;
>   +ctx->remaining = 0;
>   +ctx->limit_used = 0;
>   +ctx->limit = ap_get_limit_req_body(f->r);
>
>tenc = apr_table_get(f->r->headers_in, "Transfer-Encoding");
>lenp = apr_table_get(f->r->headers_in, "Content-Length");
>   @@ -562,6 +567,18 @@
>ctx->state = BODY_LENGTH;
>ctx->remaining = atol(lenp);
>}
>   +
>   +/* If we have a limit in effect and we know the C-L ahead of
>   + * time, stop it here if it is invalid.
>   + */
>   +if (ctx->limit && ctx->limit < ctx->remaining) {
>   +ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, 0, f->r,
>   +  "Requested content-length of %" APR_OFF_T_FMT
>   +  " is larger than the configured limit"
>   +  " of %" APR_OFF_T_FMT, ctx->remaining, ctx->limit);
>   +ap_die(HTTP_REQUEST_ENTITY_TOO_LARGE, f->r);
>   +return APR_EGENERAL;
>   +}
>

Re: Directory completion?

2002-01-02 Thread Austin Gonyou


Ok..Sorry for the craziness. There seems to be something happening with
Galeon. I tried links, again, and Mozilla and everything is working as
it should. Thanks again for all the help. It even seems as though my
filters are working correctly. 

On Wed, 2002-01-02 at 16:03, Austin Gonyou wrote:
> Thanks for all the work. I just couldn't see that happening. I don't
> care if it doesn't work for me, as long as it works for everyone else. 
> 
> Now I've got a more serious issue though. I can't even get /Galleries/
> or / to parse php now it seems. I think my ouput filters are wrong. 
> 
> I used to be able to use the following:
> 
> 
>   SetInputFilter php
>   SetOutputFilter php
>   
> 
> Now I have to use:
> 
> 
>   SetInputFilter php
>   SetOutputFilter php
> 
> 
> and likewise with html. What am I doing wrong?
> 
> -- 
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-698-7250
> email: [EMAIL PROTECTED]
> 
> "It is the part of a good shepherd to shear his flock, not to skin it."
> Latin Proverb
-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-698-7250
email: [EMAIL PROTECTED]

"It is the part of a good shepherd to shear his flock, not to skin it."
Latin Proverb



signature.asc
Description: This is a digitally signed message part

Debugging help, please?

2002-01-02 Thread Bruce Korb



Hi,

I'm trying to figure out how to use GDB or any debugger from within
a cgi program started by Apache under Linux.  I tried the obvious:

  #! /bin/sh
  DISPLAY=:0.0 xterm -e gdb /path/to/bin/exe

to no avail, so I was hoping for a hint here  :-).
The more simplistic approach of cloning the environment in a shell
script does not evidence the problem.  It only seems to be
reproducible on Linux under Apache.  (It works correctly on other
platforms or using different execution environments on Linux.)
If this is a known problem with known workarounds or fixes,
that would be even better than trying to use gdb  :-D

Thanks! - Bruce

Re: 2.0.30-dev load spiking [was: upgrade to FreeBSD 4.5-PRERELEASE]

2002-01-02 Thread Brian Pane

Greg Ames wrote:

>truss doesn't measure time on FreeBSD according to the man page.  But
>maybe there are a lot more syscalls in the failing case, so I'll try it.
>

I just took a closer look at the vmstat data, and the syscalls/second
value does indeed spike at the same time as the system CPU utilization.
So even a plain old truss might show what's going on.

--Brian

Re: Directory completion?

2002-01-02 Thread Austin Gonyou


Thanks for all the work. I just couldn't see that happening. I don't
care if it doesn't work for me, as long as it works for everyone else. 

Now I've got a more serious issue though. I can't even get /Galleries/
or / to parse php now it seems. I think my ouput filters are wrong. 

I used to be able to use the following:


  SetInputFilter php
  SetOutputFilter php
  

Now I have to use:


  SetInputFilter php
  SetOutputFilter php


and likewise with html. What am I doing wrong?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-698-7250
email: [EMAIL PROTECTED]

"It is the part of a good shepherd to shear his flock, not to skin it."
Latin Proverb



signature.asc
Description: This is a digitally signed message part

Re: 2.0.30-dev load spiking [was: upgrade to FreeBSD 4.5-PRERELEASE]

2002-01-02 Thread Justin Erenkrantz


On Wed, Jan 02, 2002 at 12:52:57PM -0800, Aaron Bannert wrote:
> On Wed, Jan 02, 2002 at 12:46:46PM -0800, Brian Pane wrote:
> > Do you have a way to take a snapshot of each httpd process's stack
> > backtrace?  On Solaris, I'd do this by running /usr/proc/bin/pstack
> > on each pid; I don't know if FreeBSD has a similar functionality.
> > This would give us a picture of what all those runnable processes
> > are doing.
> 
> Ooh, if it does I'd love to find out how. Same goes for a truss that
> can follow children, and a ps command to tell me how many threads are
> in a process.

+1.  =)  I've talked to the FreeBSD people and they just laugh
maniacally when I ask for a truss that follows children.  AIUI,
NetBSD has this, so it is possible to port these changes over, 
but it requires an overhaul to procfs from what I've been told.

FreeBSD has a long way to get the stellar debugging capabilities 
of Solaris.  -- justin

Re: 2.0.30-dev load spiking [was: upgrade to FreeBSD 4.5-PRERELEASE]

2002-01-02 Thread Greg Ames


Brian Pane wrote:
> 
> Greg Ames wrote:
> 
> >Jeff & I discussed how to troubleshoot this baby.  Some thoughts:
> >* compare trusses and look for abnormalities
> >* scrutinize the error logs
> >* calculate and log how much CPU time each request takes, the thought
> >being that some requests are burning a lot more CPU than they used to.
> >
> >Any other ideas?
> >
> 
> One more thought:  I graphed the CPU utilization from your vmstat
> output, and the spike is mostly sys time, not usr.  So truss/strace
> data may be helpful--especially if truss on that platform can measure
> the time spent in each syscall.

truss doesn't measure time on FreeBSD according to the man page.  But
maybe there are a lot more syscalls in the failing case, so I'll try it.

Greg

Re: 2.0.30-dev load spiking [was: upgrade to FreeBSD 4.5-PRERELEASE]

2002-01-02 Thread Brian Pane

Greg Ames wrote:

>Jeff & I discussed how to troubleshoot this baby.  Some thoughts:
>* compare trusses and look for abnormalities
>* scrutinize the error logs
>* calculate and log how much CPU time each request takes, the thought
>being that some requests are burning a lot more CPU than they used to.  
>
>Any other ideas?  
>

One more thought:  I graphed the CPU utilization from your vmstat
output, and the spike is mostly sys time, not usr.  So truss/strace
data may be helpful--especially if truss on that platform can measure
the time spent in each syscall.

--Brian

Re: 2.0.30-dev load spiking [was: upgrade to FreeBSD 4.5-PRERELEASE]

2002-01-02 Thread Greg Ames

Brian Pane wrote:

> Do you have a way to take a snapshot of each httpd process's stack
> backtrace?  On Solaris, I'd do this by running /usr/proc/bin/pstack
> on each pid; I don't know if FreeBSD has a similar functionality.

ummm, let's see:

[gregames@daedalus gregames]$ pstack
bash: pstack: command not found
[gregames@daedalus gregames]$ ls /usr/proc
ls: /usr/proc: No such file or directory

nope, sorry.  Of course we could get backtraces with gcore, but would
probably fill up the filesystem in the process.  

Actually, if we had a way of dumping just the two processes that own the
two CPUs when we get one of these spikes, it might be feasible. 
Especially if the trap/shell script/whatever would exit once it did its
thing, and didn't dump itself.

> This would give us a picture of what all those runnable processes
> are doing.

The processes that aren't dispatched are probably innocent bystanders,
at least until they get ahold of a CPU.  But I suppose some of them
could have been doing bad things in previous time slices.

Greg

Re: Fw: [PATCH] mod_proxy infinite cpu eating loop

2002-01-02 Thread Ryan Bloom

On Wednesday 02 January 2002 12:21 pm, Bill Stoddard wrote:
> > 1)  Fix the apr_bucket_read macro to check if this bucket is the sentinel,
> > and fail appropriately.  If we do this, we will add one if to every bucket_read
> > operation.
> >
> > 2)  Make the sentinel a more complete bucket along with a bucket->type field.
> > This bucket->type will include a no-op for the read function.
> >
> > I personally prefer option 2, but it may be a bit harder to implement.  I still 
>haven't
> > wrapped my head around the ring macros yet.
> >
> > Ryan
> 
> Yea, 2) looks good in concept, but I'm unsure how APR_BUCKET_REMOVE would be 
>implemented
> to special case removing a sentinel bucket.  The latest fix checked into proxy_util 
>should

It is already possible to try to remove a sentinel bucket, although the result
is undefined, and would most likely make things segfault quickly.  We could do
a quick check in that case, because we try to remove buckets far less often than
we try to read from them.  I am just not sure that the statement above affects
how we should implement the read function.

Ryan
__
Ryan Bloom  [EMAIL PROTECTED]
Covalent Technologies   [EMAIL PROTECTED]
--

Re: Directory completion?

2002-01-02 Thread William A. Rowe, Jr.


From: "Austin Gonyou" <[EMAIL PROTECTED]>
Sent: Wednesday, January 02, 2002 2:45 PM


Thanks for everyone's suggestions, but it's just not working.
I recently installed the new 2.0.30-dev with PHP and ssl. All working
nicely. And I tried again. 

http://digitalroadkill.net:8080/Galleries


OK.  Try this;

TELNET digitalroadkill.net 8080

GET /Galleries HTTP/1.1
Host: digitalroadkill.net:8080

I recieve;

HTTP/1.1 301 Moved Permanently
Date: Wed, 02 Jan 2002 21:06:48 GMT
Server: Apache/2.0.30-dev (Unix) mod_ssl/3.0a0 OpenSSL/0.9.6c
Location: http://digitalroadkill.net:8080/Galleries/
Content-Length: 334
Content-Type: text/html; charset=iso-8859-1



301 Moved Permanently

Moved Permanently
The document has moved http://digitalroadkill.net:8080/Galleries/";>here.

Apache/2.0.30-dev Server at digitalroadkill.net Port 8080


On a whim, I tried HEAD;

HTTP/1.1 301 Moved Permanently
Date: Wed, 02 Jan 2002 21:07:59 GMT
Server: Apache/2.0.30-dev (Unix) mod_ssl/3.0a0 OpenSSL/0.9.6c
Location: http://digitalroadkill.net:8080/Galleries/
Content-Type: text/html; charset=iso-8859-1

So checking /Galleries/ with HEAD;

HTTP/1.1 200 OK
Date: Wed, 02 Jan 2002 21:08:32 GMT
Server: Apache/2.0.30-dev (Unix) mod_ssl/3.0a0 OpenSSL/0.9.6c
Accept-Ranges: bytes
X-Powered-By: PHP/4.1.1
Content-Type: text/html; charset=ISO-8859-1

and finally GET;

HTTP/1.1 200 OK
Date: Wed, 02 Jan 2002 21:09:37 GMT
Server: Apache/2.0.30-dev (Unix) mod_ssl/3.0a0 OpenSSL/0.9.6c
Accept-Ranges: bytes
X-Powered-By: PHP/4.1.1
Content-Length: 1239
Content-Type: text/html; charset=ISO-8859-1


Emily, Katherine, and Austin




Emily, Katherine, and Austin Photo Galleries



  Available Galleries



Emily1_Gallery
Emily_Near_Birth
Emily_Almost_1
Emily_First_Birthday
Katherine_Raissle
Nearly_One
Easter_2001
Thanks_Giving_2001
Dec8_Gallery
Dec9_Gallery
Dec10_Gallery
Emily_Suitecase
Christmas_2001




mailto:[EMAIL PROTECTED]";>E-Mail Me if you have 
problems.


I see nothign wrong.  I now [very strongly] suspect your browser has cached
an invalid redirection.

Finally, I tried IE>

http://digitalroadkill.net:8080/Galleries

and was redirected to

http://digitalroadkill.net:8080/Galleries/

So this is most certainly a caching problem for your browser, and you
resolved the misconfiguration :)

Bill

Re: 2.0.30-dev load spiking [was: upgrade to FreeBSD 4.5-PRERELEASE]

2002-01-02 Thread Aaron Bannert


On Wed, Jan 02, 2002 at 12:46:46PM -0800, Brian Pane wrote:
> Do you have a way to take a snapshot of each httpd process's stack
> backtrace?  On Solaris, I'd do this by running /usr/proc/bin/pstack
> on each pid; I don't know if FreeBSD has a similar functionality.
> This would give us a picture of what all those runnable processes
> are doing.

Ooh, if it does I'd love to find out how. Same goes for a truss that
can follow children, and a ps command to tell me how many threads are
in a process.

-aaron

Re: cvs commit: apache-1.3/src/os/netware ApacheCore.imp

2002-01-02 Thread Günter Knauf


> Rebuilt and tested Apache for NetWare with the changes and everythings
> seems to checkout so far.  Just off hand I don't see anything that will
> cause us a problem.
the same; tested a bit and all fine; also Thomas's mod_rpaf now works...
Guenter.

 [EMAIL PROTECTED] Thursday, December 27, 2001 10:48:54 PM >>>
> Applied, but this needs to be double-checked on Netware.

>> wrowe   01/12/27 21:03:08
>>
>>   Modified:src  ApacheCore.def
>>src/ap   ap_snprintf.c
>>src/include ap.h ap_alloc.h buff.h
> http_conf_globals.h
>> http_config.h http_core.h http_log.h
> http_main.h
>> http_protocol.h http_request.h http_vhost.h
> httpd.h
>> rfc1413.h
>>src/main alloc.c buff.c http_config.c http_core.c
> http_log.c
>> http_main.c http_protocol.c http_request.c
>> http_vhost.c rfc1413.c util.c
>>src/os/netware ApacheCore.imp
>>   Log:
>> Normalize symbol exports for Win32/Netware to the httpd.exp
> reference.
>> Diff tags pre_win_nw_syms/post_win_nw_syms for complete edit.
>>
>> Note I've corrected _SEVERAL_ badly declared symbols on Win32
> into
>> API_EXPORT_NONSTD flavors (e.g. those using (...) args).  This
> may,
>> or may not, break binary compatibility depending on how those
> args
>> are addressed, and if those functions were used.
>>
>> I've further tested by setting aside the .def file and
> rebuilding,
>> and validated that our symbols list corresponds to the
> API_DECLARE()
>> macros at this moment.
>>
>>   Submitted by: Thomas Eibner <[EMAIL PROTECTED]>
>>   Reviewed by: Stoddard, Rowe


> Here is the list of badly declared, now _NONSTD functions (with a list
> like this,
> I'm afraid much binary compatibility will be lost);

> -API_EXPORT(int) ap_snprintf(char *buf, size_t len, const char
> *format,...)
> +API_EXPORT_NONSTD(int) ap_snprintf(char *buf, size_t len, const char
> *format,...)

> -API_EXPORT(void) ap_table_do(int (*comp) (void *, const char *, const
> char *), void *rec,
> - const table *t,...);
> +API_EXPORT_NONSTD(void) ap_table_do(int (*comp) (void *, const char *,
> const char *),
> +void *rec, const table *t,...);

> -API_EXPORT(int) ap_bvputs(BUFF *fb,...);
> +API_EXPORT_NONSTD(int) ap_bvputs(BUFF *fb,...);

> -API_EXPORT(int) ap_rprintf(request_rec *r, const char *fmt,...)
> +API_EXPORT_NONSTD(int) ap_rprintf(request_rec *r, const char
> *fmt,...)

> -API_EXPORT(void) ap_log_error(const char *file, int line, int level,
> +API_EXPORT_NONSTD(void) ap_log_error(const char *file, int line, int
> level,
>  const server_rec *s, const char *fmt, ...)

> -API_EXPORT(void) ap_log_rerror(const char *file, int line, int level,
> +API_EXPORT_NONSTD(void) ap_log_rerror(const char *file, int line, int
> level,
>  const request_rec *s, const char *fmt, ...)

> -API_EXPORT(void) ap_log_printf(const server_rec *s, const char *fmt,
> ...)
> +API_EXPORT_NONSTD(void) ap_log_printf(const server_rec *s, const char
> *fmt, ...)


> And finally, here is a list of the differences remaining between
> httpd.exp and the
> win32 exported symbols.  I'm posting the list mostly because someone
> might want to
> go back over httpd.exp, since some win32 inclusions should fall in the
> httpd.exp
> list.  Also, there are a few more missing symbols in the win32 list yet
> to be fixed.

> --- httpd.exp Thu Dec 27 23:07:54 2001
> +++ declared.ref Thu Dec 27 23:45:46 2001
> +access_module
> +alias_module
> +ap_acquire_mutex
> +ap_add_loaded_module
> +ap_bpushh
> +ap_check_alarm
> -ap_child_terminate
> +ap_create_mutex
> +ap_destroy_mutex
> -ap_dummy_mutex
> +ap_get_limit_req_body
> +ap_get_service_key
> +ap_get_win32_interpreter
> -ap_listeners
> +ap_loaded_modules
> +ap_md5_binary
> +ap_note_cleanups_for_h
> +ap_open_mutex
> +ap_os_canonical_filename
> +ap_os_case_canonical_filename
> +ap_os_dso_error
> +ap_os_dso_load
> -ap_os_is_path_absolute
> +ap_os_is_filename_valid
> +ap_os_systemcase_filename
> +ap_pcloseh
> -ap_prelinked_modules
> -ap_preloaded_modules
> -ap_register_other_child
> +ap_registry_get_server_root
> +ap_release_mutex
> +ap_remove_loaded_module
> -ap_rfc1413_timeout
> +ap_scan_script_header_err_core
> -ap_signal
> -ap_slack
> -ap_sys_siglist
> -ap_unregister_other_child
> -ap_util_init
> -ap_util_uri_init
> +ap_uuencode
> +apache_main
> +asis_module
> +auth_module
> +autoindex_module
> +cgi_module
> +closedir
> +config_log_module
> +dir_module
> +env_module
> +imap_module
> +includes_module
> +mime_module
> +negotiation_module
> +opendir
> +os_spawnle
> +os_spawnv
> +os_spawnve
> +os_stat
> +os_strftime
> +readdir
> +regcomp
> +regerror
> +regexec
> +regfree
> +setenvif_module
> +so_module
> -XML_DefaultCurrent
> -XML_ErrorString
> -XML_ExternalEntityParserCreate
> -XML_GetBase
> -XML_GetBuffer
> -XML_GetCurrentByteCo

Re: 2.0.30-dev load spiking [was: upgrade to FreeBSD 4.5-PRERELEASE]

2002-01-02 Thread Rodent of Unusual Size


Bill Stoddard wrote:
> 
>SetEnvIf ^TS* ^[a-z].*  GET_TIMESTAMP
>Header echo ^TS*

If these are REs, shouldn't that be ^TS.*, at least in the
first one?
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: Directory completion?

2002-01-02 Thread Austin Gonyou


Thanks for everyone's suggestions, but it's just not working.
I recently installed the new 2.0.30-dev with PHP and ssl. All working
nicely. And I tried again. 

http://digitalroadkill.net:8080/Galleries

versus 

http://digitalroadkill.net:8080/Gallieries/

One produces a timeout, the other doesn't. 

I'll turn my logs up to debug and see if I can see anything. I haven't
been able to so far. I'm using worker MPM on Linux. 
glibc 2.2.4, gcc 3.0.2 compiled.

Thanks again. 

On Mon, 2001-12-31 at 17:53, Aaron Bannert wrote:
> On Mon, Dec 31, 2001 at 05:36:22PM -0600, Austin Gonyou wrote:
> > If I add a directory to my httpd.conf and restart apache, or I add a
> > directory to htdocs, then point my browser as such:
> > 
> > http://127.0.0.1/somedir
> > 
> > It hangs until the browser times out. If I do the following though,
> > without restarting apache, etc:
> 
> My guess is your ServerName is set to something that doesn't exist from
> the perspective of your browser. When you request
> http://127.0.0.1/somedir
> it generates a 301 Moved Permanently to whatever was in your ServerName
> (plus the path and some other stuff), at which point your browser tries
> to resolve that new host. If it cannot it will hang until timeout.
> 
> > http://127.0.0.1/somedir/ 
> 
> This one doesn't generate a 301 since it is a properly formed URL
> (it references a real resource).
> 
> > it works. Why is that, and what am I missing. It seems so simple, yet
> I
> > don't understand what option I'm missing. 
> 
> -aaron
-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-698-7250
email: [EMAIL PROTECTED]

"It is the part of a good shepherd to shear his flock, not to skin it."
Latin Proverb



signature.asc
Description: This is a digitally signed message part

Re: 2.0.30-dev load spiking [was: upgrade to FreeBSD 4.5-PRERELEASE]

2002-01-02 Thread Brian Pane


Greg Ames wrote:

>when I came in to work today, top on daedalus showed all three load
>averages above 27. vmstat -w 5 showed that the number of processes in
>the run queue was jumping up to over 350 fairly frequently, and there's
>some evidence of spikes in CPU usage.  So I bounced us back to httpd
>2_0_28, and the bad behavior has definately gotten better.
>
>Either we're doing something to make more processes run-able at times,
>or httpd related processes are staying in the run queue longer than they
>used to sometimes.  I think it's the latter.  For one thing, the idle
>CPU drops down to zero periodically, which I've never seen with 2_0_28.  
>
>Jeff & I discussed how to troubleshoot this baby.  Some thoughts:
>* compare trusses and look for abnormalities
>* scrutinize the error logs
>* calculate and log how much CPU time each request takes, the thought
>being that some requests are burning a lot more CPU than they used to.  
>
>Any other ideas?  
>

Do you have a way to take a snapshot of each httpd process's stack
backtrace?  On Solaris, I'd do this by running /usr/proc/bin/pstack
on each pid; I don't know if FreeBSD has a similar functionality.
This would give us a picture of what all those runnable processes
are doing.

--Brian

Re: 2.0.30-dev load spiking [was: upgrade to FreeBSD 4.5-PRERELEASE]

2002-01-02 Thread Bill Stoddard


Humm... I put some changes into mod_headers a while back that -might- be useful.  You 
can
have the time it took to serve the request sent back in a header on the response with 
the
following directives:


   SetEnvIf ^TS* ^[a-z].*  GET_TIMESTAMP



   Header add TS-DeltaTime "%t %D"  env=GET_TIMESTAMP
   Header echo ^TS*


The TS-DeltaTime header will be conditionally sent based on whether GET_TIMESTAMP 
envar is
set.

Bill

- Original Message -
From: "Greg Ames" <[EMAIL PROTECTED]>
To: "httpd" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, January 02, 2002 3:14 PM
Subject: 2.0.30-dev load spiking [was: upgrade to FreeBSD 4.5-PRERELEASE]


> when I came in to work today, top on daedalus showed all three load
> averages above 27. vmstat -w 5 showed that the number of processes in
> the run queue was jumping up to over 350 fairly frequently, and there's
> some evidence of spikes in CPU usage.  So I bounced us back to httpd
> 2_0_28, and the bad behavior has definately gotten better.
>
> Either we're doing something to make more processes run-able at times,
> or httpd related processes are staying in the run queue longer than they
> used to sometimes.  I think it's the latter.  For one thing, the idle
> CPU drops down to zero periodically, which I've never seen with 2_0_28.
>
> Jeff & I discussed how to troubleshoot this baby.  Some thoughts:
> * compare trusses and look for abnormalities
> * scrutinize the error logs
> * calculate and log how much CPU time each request takes, the thought
> being that some requests are burning a lot more CPU than they used to.
>
> Any other ideas?
>
> If this isn't a showstopper, it's close.
>
> Greg
> -
> (with 2.0.30-dev)
>
> [gregames@daedalus gregames]$ top
> last pid:  3248;  load averages: 39.32, 32.01, 27.17up 4+16:31:26
> 06:49:45
> 552 processes: 8 running, 541 sleeping, 3 zombie
> CPU states: 18.1% user,  0.0% nice, 23.8% system,  4.2% interrupt, 53.8%
> idle
> [...]
> [gregames@daedalus gregames]$ top
> last pid:  3517;  load averages: 14.83, 26.29, 25.36up 4+16:32:21
> 06:50:40
> 467 processes: 255 running, 210 sleeping, 2 zombie
> CPU states:  0.8% user,  0.0% nice, 11.6% system,  2.5% interrupt, 85.1%
> idle
> [...]
> [gregames@daedalus gregames]$ vmstat -w 5
>
> (first column is the size of the run queue; last column is idle CPU)
>
>  procs  memory  pagedisks faults
> cpu
>  r b w avmfre  flt  re  pi  po  fr  sr da0 da1   in   sy  cs us
> sy id
> 21 3 0  360208  83460  309   2   1   0 329  64   0   0  675 2543 1480
> 4  5 90
> 65 3 0  355192  84776  564   2   1   0 618   0  49   7 1238 4590 7486  9
> 19 73
> 72 3 0  350932  84324  594   6   2   0 607   0  75  10 1392 5040 8431 10
> 20 70
> 53 4 0  347908  83620  682   4   2   0 660   0  53   8 1280 5072 8647 10
> 20 69
> 360 3 0  346000  82164 1336   3   4   0 1162   0  80  11 1415 8164 8891
> 26 27 47
> 19 4 0  346792  80344  606   1   2   0 559   0  14  10 1283 4140 8060 11
> 19 71
> 18 3 0  337024  79208  498   9   2   0 596   0  15  21 1598 4979 6531 11
> 20 70
> 12 4 0  343628  71740  818   4   2   0 546   0  63  13 1449 5099 6503  9
> 18 73
> 26 3 0  352104  65332 1322   5   3   0 930   0  66  14 1340 8979 7786 11
> 25 64
> 25 5 0  387428  46428 5383   4   2   0 4397   0  16   9 1876 27473 15659
> 29 71 0
> 40 6 0  404196  36828 5136   2   2   0 3927   0  46  12 2050 25730 15231
> 28 72 0
> 26 3 0  390944  67624 3763   3   3   0 3513 1365  53  12 2042 21203
> 15966 22 69 9
> 388 6 0  354580  82856  572   2   2   0 1325   0  28   6 1305 7314
> 10551  9 28 62
> 356 4 0  341624  86328 1247   2   1   0 1369   0  70   8 1225 4977 6641
> 20 20 60
> 12 3 0  338044  86392  384   8   3   0 384   0   1  10 1028 3300 6861 14
> 15 71
> 341 3 0  336016  85280   24   9   3   0  48   0   0   8 1010 2983 6120
> 4 14 83
> 18 3 0  327908  86340  660   5   3   0 696   0  11   9 1112 3515 6304 13
> 16 71
> 320 3 0  322972  85720  522   2   2   0 512   0   3  14 1083 3043 5146
> 14 12 74
>  8 3 0  323028  83276  255   3   2   0 211   0  12  11 1112 2712 4367  4
> 11 85
>
> -
> (with 2_0_28)
>
> [gregames@daedalus gregames]$ top
> last pid: 43953;  load averages:  0.48,  0.62,  0.81  up 4+21:09:23
> 11:27:42
> 258 processes: 1 running, 257 sleeping
> CPU states:  2.8% user,  0.0% nice,  5.1% system,  2.4% interrupt, 89.8%
> idle
>
> [gregames@daedalus gregames]$ vmstat -w 5
>  procs  memory  pagedisks faults
> cpu
>  r b w avmfre  flt  re  pi  po  fr  sr da0 da1   in   sy  cs us
> sy id
>  8 3 0  347520  56464  324   2   1   0 342  65   0   0  693 2645 1499
> 4  6 90
> 63 3 0  341884  57496  356   6   0   0 403   0   4   8  754 2451 1372
> 8  5 87
> 19 3 0  341808  56672  386   0   1   0 353   0   7  10  886 2829 1273
> 8  7 86
> 35 3 0  351424  53896  219   3   2

Re: Fw: [PATCH] mod_proxy infinite cpu eating loop

2002-01-02 Thread Bill Stoddard


> On Wednesday 02 January 2002 10:34 am, Bill Stoddard wrote:
> > I see this pattern several places in the code:
> >
> > rc = apr_get_brigade();
> > if (rc != APR_SUCCESS) {
> >fail;
> > }
> > /* Is the brigade empty? */
> > if (APR_BRIGADE_EMPTY(b)) {
> >fail;
> > }
> > /* Get first bucket */
> > e = APR_BRIGADE_FIRST(b);
> >
> > /* Is the bucket an EOS? */
> > if (APR_BUCKET_IS_EOS(e)) {
> > }
> >
> > /* Does the bucket have zero length? */
> > if (e->length == 0) {
> > }
> >
> > You have to make these checks each and everytime we fetch a brigade which seems
> > unintuitive. Should a apr_bucket_read() call on a bucket with e->length == 0 cause 
>a
seg
> > fault? Seems this check is masking a deeper problem.
>
> A bucket_read on a bucket with e->length == 0 should not seg fault, but that isn't
> what is happening here.  What is actually happening is that we are calling bucket
> read on the sentinel which is seg faulting.  The problem is that the sentinel is kind
> of a fake bucket, so it doesn't actually have a bucket->type field, but we are
> trying to use the bucket->type to find the read function,  which causes us
> to segfault.
>
> There are a few possible solutions:
>
> 1)  Fix the apr_bucket_read macro to check if this bucket is the sentinel,
> and fail appropriately.  If we do this, we will add one if to every bucket_read
> operation.
>
> 2)  Make the sentinel a more complete bucket along with a bucket->type field.
> This bucket->type will include a no-op for the read function.
>
> I personally prefer option 2, but it may be a bit harder to implement.  I still 
>haven't
> wrapped my head around the ring macros yet.
>
> Ryan

Yea, 2) looks good in concept, but I'm unsure how APR_BUCKET_REMOVE would be 
implemented
to special case removing a sentinel bucket.  The latest fix checked into proxy_util 
should
avoid the segfault in ap_proxy_string_read() (Thanks Adam!)

I am beginning to collect some notes to put into a 'how-to' document for developers. 
There
are certain patterns that repeat all over the server and it would be good to codify 
that
knowledge in one reference document.

Bill

2.0.30-dev load spiking [was: upgrade to FreeBSD 4.5-PRERELEASE]

2002-01-02 Thread Greg Ames


when I came in to work today, top on daedalus showed all three load
averages above 27. vmstat -w 5 showed that the number of processes in
the run queue was jumping up to over 350 fairly frequently, and there's
some evidence of spikes in CPU usage.  So I bounced us back to httpd
2_0_28, and the bad behavior has definately gotten better.

Either we're doing something to make more processes run-able at times,
or httpd related processes are staying in the run queue longer than they
used to sometimes.  I think it's the latter.  For one thing, the idle
CPU drops down to zero periodically, which I've never seen with 2_0_28.  

Jeff & I discussed how to troubleshoot this baby.  Some thoughts:
* compare trusses and look for abnormalities
* scrutinize the error logs
* calculate and log how much CPU time each request takes, the thought
being that some requests are burning a lot more CPU than they used to.  

Any other ideas?  

If this isn't a showstopper, it's close.

Greg
-
(with 2.0.30-dev)

[gregames@daedalus gregames]$ top
last pid:  3248;  load averages: 39.32, 32.01, 27.17up 4+16:31:26 
06:49:45
552 processes: 8 running, 541 sleeping, 3 zombie
CPU states: 18.1% user,  0.0% nice, 23.8% system,  4.2% interrupt, 53.8%
idle
[...]
[gregames@daedalus gregames]$ top
last pid:  3517;  load averages: 14.83, 26.29, 25.36up 4+16:32:21 
06:50:40
467 processes: 255 running, 210 sleeping, 2 zombie
CPU states:  0.8% user,  0.0% nice, 11.6% system,  2.5% interrupt, 85.1%
idle
[...]
[gregames@daedalus gregames]$ vmstat -w 5

(first column is the size of the run queue; last column is idle CPU)

 procs  memory  pagedisks faults 
cpu
 r b w avmfre  flt  re  pi  po  fr  sr da0 da1   in   sy  cs us
sy id
21 3 0  360208  83460  309   2   1   0 329  64   0   0  675 2543 1480 
4  5 90
65 3 0  355192  84776  564   2   1   0 618   0  49   7 1238 4590 7486  9
19 73
72 3 0  350932  84324  594   6   2   0 607   0  75  10 1392 5040 8431 10
20 70
53 4 0  347908  83620  682   4   2   0 660   0  53   8 1280 5072 8647 10
20 69
360 3 0  346000  82164 1336   3   4   0 1162   0  80  11 1415 8164 8891
26 27 47
19 4 0  346792  80344  606   1   2   0 559   0  14  10 1283 4140 8060 11
19 71
18 3 0  337024  79208  498   9   2   0 596   0  15  21 1598 4979 6531 11
20 70
12 4 0  343628  71740  818   4   2   0 546   0  63  13 1449 5099 6503  9
18 73
26 3 0  352104  65332 1322   5   3   0 930   0  66  14 1340 8979 7786 11
25 64
25 5 0  387428  46428 5383   4   2   0 4397   0  16   9 1876 27473 15659
29 71 0
40 6 0  404196  36828 5136   2   2   0 3927   0  46  12 2050 25730 15231
28 72 0
26 3 0  390944  67624 3763   3   3   0 3513 1365  53  12 2042 21203
15966 22 69 9
388 6 0  354580  82856  572   2   2   0 1325   0  28   6 1305 7314
10551  9 28 62
356 4 0  341624  86328 1247   2   1   0 1369   0  70   8 1225 4977 6641
20 20 60
12 3 0  338044  86392  384   8   3   0 384   0   1  10 1028 3300 6861 14
15 71
341 3 0  336016  85280   24   9   3   0  48   0   0   8 1010 2983 6120 
4 14 83
18 3 0  327908  86340  660   5   3   0 696   0  11   9 1112 3515 6304 13
16 71
320 3 0  322972  85720  522   2   2   0 512   0   3  14 1083 3043 5146
14 12 74
 8 3 0  323028  83276  255   3   2   0 211   0  12  11 1112 2712 4367  4
11 85
 
-
(with 2_0_28)

[gregames@daedalus gregames]$ top
last pid: 43953;  load averages:  0.48,  0.62,  0.81  up 4+21:09:23 
11:27:42
258 processes: 1 running, 257 sleeping
CPU states:  2.8% user,  0.0% nice,  5.1% system,  2.4% interrupt, 89.8%
idle

[gregames@daedalus gregames]$ vmstat -w 5
 procs  memory  pagedisks faults 
cpu
 r b w avmfre  flt  re  pi  po  fr  sr da0 da1   in   sy  cs us
sy id
 8 3 0  347520  56464  324   2   1   0 342  65   0   0  693 2645 1499 
4  6 90
63 3 0  341884  57496  356   6   0   0 403   0   4   8  754 2451 1372 
8  5 87
19 3 0  341808  56672  386   0   1   0 353   0   7  10  886 2829 1273 
8  7 86
35 3 0  351424  53896  219   3   2   0 122   0   0  14 1023 2481 1033 
4  8 88
 7 3 0  351504  52840   31   1   1   0   1   0   1   4  916 2326 1180 
2  5 93
68 3 0  431392  39536 4274   1   2   0 3315 1363  61   5 1504 19223 4338
21 46 34
16 3 0  382092  62120  681   1   3   0 1806   0  10   4 1422 8630 2455 
5 22 73
13 3 0  371612  66116  700   9   6   0 822   0  11   9  988 4534 1637 10
10 80
45 3 0  360188  67256  449   2   3   0 480   0  20   5 1024 4424 1347 
6  9 85
11 3 0  357000  66488 1809   1   1   0 1664   0   7   8  864 18482 1276 
4 17 79
16 3 0  356388  65428  301   1   1   0 276   0   9   8 1140 3559 1490
10  9 81
15 3 0  353324  62920  139   1   1   0 138   0  36  11 1069 3355 1545 
4  6 89
 9 4 0  351680  60328  665   3   1   0 550   0  25  14 1123 4700 1474 12
10 79
35 3 0  350108  59352  930   3   1   0 865   0  27   7 1047 7593 1224 10
10 81
65 3 0  35

Re: Fw: [PATCH] mod_proxy infinite cpu eating loop

2002-01-02 Thread Ryan Bloom

On Wednesday 02 January 2002 10:34 am, Bill Stoddard wrote:
> I see this pattern several places in the code:
> 
> rc = apr_get_brigade();
> if (rc != APR_SUCCESS) {
>fail;
> }
> /* Is the brigade empty? */
> if (APR_BRIGADE_EMPTY(b)) {
>fail;
> }
> /* Get first bucket */
> e = APR_BRIGADE_FIRST(b);
> 
> /* Is the bucket an EOS? */
> if (APR_BUCKET_IS_EOS(e)) {
> }
> 
> /* Does the bucket have zero length? */
> if (e->length == 0) {
> }
> 
> You have to make these checks each and everytime we fetch a brigade which seems
> unintuitive. Should a apr_bucket_read() call on a bucket with e->length == 0 cause a 
>seg
> fault? Seems this check is masking a deeper problem.

A bucket_read on a bucket with e->length == 0 should not seg fault, but that isn't
what is happening here.  What is actually happening is that we are calling bucket
read on the sentinel which is seg faulting.  The problem is that the sentinel is kind
of a fake bucket, so it doesn't actually have a bucket->type field, but we are
trying to use the bucket->type to find the read function,  which causes us
to segfault.

There are a few possible solutions:

1)  Fix the apr_bucket_read macro to check if this bucket is the sentinel,
and fail appropriately.  If we do this, we will add one if to every bucket_read
operation.

2)  Make the sentinel a more complete bucket along with a bucket->type field.
This bucket->type will include a no-op for the read function.

I personally prefer option 2, but it may be a bit harder to implement.  I still haven't
wrapped my head around the ring macros yet.

Ryan

__
Ryan Bloom  [EMAIL PROTECTED]
Covalent Technologies   [EMAIL PROTECTED]
--

Re: [PATCH] Win32/NetWare sockets.c

2002-01-02 Thread Bill Stoddard


Your patch has the wrong polarity (the code you are adding is marked with '-' rather 
than
'+'). Please post the corrected patch and I'll look at it.

Bill

- Original Message -
From: "Brad Nicholes" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, January 02, 2002 2:25 PM
Subject: [PATCH] Win32/NetWare sockets.c


> Any feedback would be appreciated.  If it looks OK then I will go ahead
> and check it in.
>
> Brad
>
> >>> "William A. Rowe, Jr." <[EMAIL PROTECTED]> Wednesday, January 02,
> 2002 12:12:59 PM >>>
> I'll look at this this afternoon ... but Mr's Stoddard and Trawick
> have
> a wee bit of insight about Win32 Sockets API [much more than myself]
> and
> might be interested as well.
>
> Bill
>
> - Original Message -
> From: "Brad Nicholes" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, January 02, 2002 10:37 AM
> Subject: Changes to sockets.c
>
>
> > Bill,
> > Would you mind taking a quick look at this before I check it in.
>
> > Basically I moved the call to accept() before allocating the
> > apr_socket_t structure so that I can do non-blocking accepts without
> > chewing up a huge chunk of memory on WSAEWOULDBLOCK's.  No need to
> > allocate memory if it would have blocked anyway or recieved some
> other
> > error.  FYI, there may be other places where the APR functions don't
> > accomodate a non-blocking scheme, but I haven't had the time to look
> > into it yet.
> >
> > thanks,
> > Brad
> >
>

Fw: cvs commit: httpd-2.0/modules/proxy proxy_util.c

2002-01-02 Thread Bill Stoddard


Adam,
Could you try this out and report the results?  I'm guessing that an EOS bucket was 
being
encountered and removed from the brigade, leaving an empty brigade. APR_BRIGADE_FIRST 
then
returned a bogus bucket and we segfaulted when trying to read from that bogus bucket.

I think this code is more correct than the code it replaces. Only guessing that it will
prevent the segfault though.

Bill

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 02, 2002 2:12 PM
Subject: cvs commit: httpd-2.0/modules/proxy proxy_util.c


> stoddard02/01/02 11:12:40
>
>   Modified:modules/proxy proxy_util.c
>   Log:
>   Change the return code from APR_TIMEUP to APR_ECONNABORTED, which seems
>   to be a bit more descriptive. Move the check to inside the inner while()
>   loop and add an additional check for eos. If we get an EOS bucket, there
>   is no point in going further. Hopefully this will fix the last seg fault
>   in the function.
>
>   Revision  ChangesPath
>   1.76  +4 -5  httpd-2.0/modules/proxy/proxy_util.c
>
>   Index: proxy_util.c
>   ===
>   RCS file: /home/cvs/httpd-2.0/modules/proxy/proxy_util.c,v
>   retrieving revision 1.75
>   retrieving revision 1.76
>   diff -u -r1.75 -r1.76
>   --- proxy_util.c 31 Dec 2001 20:43:59 - 1.75
>   +++ proxy_util.c 2 Jan 2002 19:12:40 - 1.76
>   @@ -1020,13 +1020,12 @@
>&zero /* readline */))) {
>return rv;
>}
>   -if (APR_BRIGADE_EMPTY(bb)) {
>   -/* The connection aborted or timed out */
>   -return APR_TIMEUP;
>   -}
>   -
>/* loop through each bucket */
>while (!found) {
>   +if (*eos || APR_BRIGADE_EMPTY(bb)) {
>   +/* The connection aborted or timed out */
>   +return APR_ECONNABORTED;
>   +}
>e = APR_BRIGADE_FIRST(bb);
>if (APR_BUCKET_IS_EOS(e)) {
>*eos = 1;
>
>
>
>

[PATCH] Win32/NetWare sockets.c

2002-01-02 Thread Brad Nicholes


Any feedback would be appreciated.  If it looks OK then I will go ahead
and check it in.

Brad

>>> "William A. Rowe, Jr." <[EMAIL PROTECTED]> Wednesday, January 02,
2002 12:12:59 PM >>>
I'll look at this this afternoon ... but Mr's Stoddard and Trawick
have
a wee bit of insight about Win32 Sockets API [much more than myself]
and
might be interested as well.

Bill

- Original Message - 
From: "Brad Nicholes" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 02, 2002 10:37 AM
Subject: Changes to sockets.c


> Bill,
> Would you mind taking a quick look at this before I check it in.

> Basically I moved the call to accept() before allocating the
> apr_socket_t structure so that I can do non-blocking accepts without
> chewing up a huge chunk of memory on WSAEWOULDBLOCK's.  No need to
> allocate memory if it would have blocked anyway or recieved some
other
> error.  FYI, there may be other places where the APR functions don't
> accomodate a non-blocking scheme, but I haven't had the time to look
> into it yet.
> 
> thanks,
> Brad
> 


--- sockets.c   Wed Dec 19 14:55:41 2001
+++ d:\tempapache\apr\network_io\win32\sockets.cTue Dec 11 09:24:02 2001
@@ -226,26 +226,20 @@
 APR_DECLARE(apr_status_t) apr_accept(apr_socket_t **new, apr_socket_t *sock,
  apr_pool_t *p)
 {
-SOCKET s;
-struct sockaddr sa;
-int salen = sizeof(sock->remote_addr->sa);
-
-// Don't allocate the memory until after we call accept. This allows
-//  us to work with nonblocking sockets.
-s = accept(sock->sock, (struct sockaddr *)&sa, &salen);
-if (s == INVALID_SOCKET) {
-return apr_get_netos_error();
-}
-
 alloc_socket(new, p);
 set_socket_vars(*new, sock->local_addr->sa.sin.sin_family, SOCK_STREAM);
 
 (*new)->timeout = -1;   
 (*new)->disconnected = 0;
 
-(*new)->sock = s;
 (*new)->remote_addr->salen = sizeof((*new)->remote_addr->sa);
-memcpy (&(*new)->remote_addr->sa, &sa, salen);
+(*new)->sock = accept(sock->sock, 
+  (struct sockaddr *)&(*new)->remote_addr->sa,
+  &(*new)->remote_addr->salen);
+
+if ((*new)->sock == INVALID_SOCKET) {
+return apr_get_netos_error();
+}
 *(*new)->local_addr = *sock->local_addr;
 
 /* The above assignment just overwrote the pool entry. Setting the local_addr

Re: Fw: [PATCH] mod_proxy infinite cpu eating loop

2002-01-02 Thread Justin Erenkrantz

On Wed, Jan 02, 2002 at 01:34:57PM -0500, Bill Stoddard wrote:
> I see this pattern several places in the code:
> 
> rc = apr_get_brigade();
> if (rc != APR_SUCCESS) {
>fail;
> }
> /* Is the brigade empty? */
> if (APR_BRIGADE_EMPTY(b)) {
>fail;
> }
> /* Get first bucket */
> e = APR_BRIGADE_FIRST(b);
> 
> /* Is the bucket an EOS? */
> if (APR_BUCKET_IS_EOS(e)) {
> }
> 
> /* Does the bucket have zero length? */
> if (e->length == 0) {
> }
> 
> You have to make these checks each and everytime we fetch a brigade which seems
> unintuitive. Should a apr_bucket_read() call on a bucket with e->length == 0 cause a 
>seg
> fault? Seems this check is masking a deeper problem.

Yeah, this is wonky, but a brigade-using function *should* be able to
handle a 0-length bucket.  I can't imagine why it shouldn't.

However, when the socket bucket disappears in apr_bucket_read, we often
morph it to an immortal bucket of length 0.  What I'm not sure is if 
that happens to get returned by core_input_filter or not - this 
morning, I'm thinking it doesn't.  Last night, I thought it did.

Last night, I did remove one of the cases where the 0-length bucket
is inserted into the returned brigade.  But, I think the socket may
still muck things up.  -- justin

Re: cvs commit: apache-1.3/src/os/netware ApacheCore.imp

2002-01-02 Thread Pavel Novy


Tested those new changes on build with the GNU tools and it seems that 
there is a problem with new ApacheCore.imp file. It's not a new one - a 
nlmconv utility used here for NLM linking is not able to allocate a 
physical space for uninitialized variables, so if any of such symbols is 
exported (nlmconv doesn't produce any warning), it's not possible to 
load a NLM module, then. The core module (apachec.nlm) is affected and 
the only way to fix this is to change those uninitialized variables to 
initialized (yes, we also could ask for fix in the nlmconv utility, but 
it's much harder). I will take a look which variable(s) is(are) causing 
this and will let you know.

Pavel

Brad Nicholes wrote:

> Rebuilt and tested Apache for NetWare with the changes and everythings
> seems to checkout so far.  Just off hand I don't see anything that will
> cause us a problem.
> 
> 
[EMAIL PROTECTED] Thursday, December 27, 2001 10:48:54 PM >>>

> Applied, but this needs to be double-checked on Netware.
> 
> 
>>wrowe   01/12/27 21:03:08
>>
>>  Modified:src  ApacheCore.def
>>   src/ap   ap_snprintf.c
>>   src/include ap.h ap_alloc.h buff.h
>>
> http_conf_globals.h
> 
>>http_config.h http_core.h http_log.h
>>
> http_main.h
> 
>>http_protocol.h http_request.h http_vhost.h
>>
> httpd.h
> 
>>rfc1413.h
>>   src/main alloc.c buff.c http_config.c http_core.c
>>
> http_log.c
> 
>>http_main.c http_protocol.c http_request.c
>>http_vhost.c rfc1413.c util.c
>>   src/os/netware ApacheCore.imp
>>  Log:
>>Normalize symbol exports for Win32/Netware to the httpd.exp
>>
> reference.
> 
>>Diff tags pre_win_nw_syms/post_win_nw_syms for complete edit.
>>  
>>Note I've corrected _SEVERAL_ badly declared symbols on Win32
>>
> into
> 
>>API_EXPORT_NONSTD flavors (e.g. those using (...) args).  This
>>
> may,
> 
>>or may not, break binary compatibility depending on how those
>>
> args
> 
>>are addressed, and if those functions were used.
>>  
>>I've further tested by setting aside the .def file and
>>
> rebuilding,
> 
>>and validated that our symbols list corresponds to the
>>
> API_DECLARE()
> 
>>macros at this moment.
>>  
>>  Submitted by: Thomas Eibner <[EMAIL PROTECTED]>
>>  Reviewed by: Stoddard, Rowe
>>
> 
> 
> Here is the list of badly declared, now _NONSTD functions (with a list
> like this,
> I'm afraid much binary compatibility will be lost);
> 
> -API_EXPORT(int) ap_snprintf(char *buf, size_t len, const char
> *format,...)
> +API_EXPORT_NONSTD(int) ap_snprintf(char *buf, size_t len, const char
> *format,...)
> 
> -API_EXPORT(void) ap_table_do(int (*comp) (void *, const char *, const
> char *), void *rec,
> - const table *t,...);
> +API_EXPORT_NONSTD(void) ap_table_do(int (*comp) (void *, const char *,
> const char *), 
> +void *rec, const table *t,...);
> 
> -API_EXPORT(int) ap_bvputs(BUFF *fb,...);
> +API_EXPORT_NONSTD(int) ap_bvputs(BUFF *fb,...);
> 
> -API_EXPORT(int) ap_rprintf(request_rec *r, const char *fmt,...)
> +API_EXPORT_NONSTD(int) ap_rprintf(request_rec *r, const char
> *fmt,...)
> 
> -API_EXPORT(void) ap_log_error(const char *file, int line, int level,
> +API_EXPORT_NONSTD(void) ap_log_error(const char *file, int line, int
> level,
>  const server_rec *s, const char *fmt, ...)
> 
> -API_EXPORT(void) ap_log_rerror(const char *file, int line, int level,
> +API_EXPORT_NONSTD(void) ap_log_rerror(const char *file, int line, int
> level,
>  const request_rec *s, const char *fmt, ...)
> 
> -API_EXPORT(void) ap_log_printf(const server_rec *s, const char *fmt,
> ...)
> +API_EXPORT_NONSTD(void) ap_log_printf(const server_rec *s, const char
> *fmt, ...)
> 
> 
> And finally, here is a list of the differences remaining between
> httpd.exp and the
> win32 exported symbols.  I'm posting the list mostly because someone
> might want to
> go back over httpd.exp, since some win32 inclusions should fall in the
> httpd.exp
> list.  Also, there are a few more missing symbols in the win32 list yet
> to be fixed.
> 
> --- httpd.exp Thu Dec 27 23:07:54 2001
> +++ declared.ref Thu Dec 27 23:45:46 2001
> +access_module
> +alias_module
> +ap_acquire_mutex
> +ap_add_loaded_module
> +ap_bpushh
> +ap_check_alarm
> -ap_child_terminate
> +ap_create_mutex
> +ap_destroy_mutex
> -ap_dummy_mutex
> +ap_get_limit_req_body
> +ap_get_service_key
> +ap_get_win32_interpreter
> -ap_listeners
> +ap_loaded_modules
> +ap_md5_binary
> +ap_note_cleanups_for_h
> +ap_open_mutex
> +ap_os_canonical_filename
> +ap_os_case_canonical_filename
> +ap_os_dso_error
> +ap_os_dso_load
> -ap_os_is_path_absolute
> +ap_os_is_filename_valid
> +ap_os_systemcase_filename
> +ap_pcloseh
> -ap_prelinked_modules
> -ap_preloaded_modules
> -ap_register_other_child
> +ap_registry_get_server_root
> +ap_release_mutex
> +a

Re: [PATCH] mod_proxy infinite cpu eating loop

2002-01-02 Thread Bill Stoddard


Can you identify where the seg fault is happening? I am really suspicious of why 
checking
for length == 0 would avoid the segfault. As I mentioned in an earlier post, I suspect
this check is masking another problem.

Thanks,
Bill

>
> Bill,
>
> Everything looks good except that ap_proxy_string_read() now segfaults on
> its apr_bucket_read().  It appears that APR_BRIGADE_EMPTY is not sufficient
> to detect the case of the closed socket with no data.  I suspect that this
> is because the core filter seeds the brigade with a socket bucket and that
> this is what is giving apr_bucket_read problems.
>
> This bit of code seems to do the trick, but again I am still a little unsure
> of my footing with filters and buckets.
>
> -adam
>
>
> Index: proxy_util.c
> ===
> RCS file: /home/cvspublic/httpd-2.0/modules/proxy/proxy_util.c,v
> retrieving revision 1.75
> diff -u -r1.75 proxy_util.c
> --- proxy_util.c 31 Dec 2001 20:43:59 - 1.75
> +++ proxy_util.c 2 Jan 2002 01:29:58 -
> @@ -1031,7 +1031,13 @@
>  if (APR_BUCKET_IS_EOS(e)) {
>  *eos = 1;
>  }
> +else if (e->length == 0) {
> +APR_BUCKET_REMOVE(e);
> +apr_bucket_destroy(e);
> +break;
> +}
>  else {
> +
>  if (APR_SUCCESS != apr_bucket_read(e, (const char **)&response, 
>&len,
APR_BLOCK_READ)) {
>  return rv;
>  }
>

Fw: [PATCH] mod_proxy infinite cpu eating loop

2002-01-02 Thread Bill Stoddard


I see this pattern several places in the code:

rc = apr_get_brigade();
if (rc != APR_SUCCESS) {
   fail;
}
/* Is the brigade empty? */
if (APR_BRIGADE_EMPTY(b)) {
   fail;
}
/* Get first bucket */
e = APR_BRIGADE_FIRST(b);

/* Is the bucket an EOS? */
if (APR_BUCKET_IS_EOS(e)) {
}

/* Does the bucket have zero length? */
if (e->length == 0) {
}

You have to make these checks each and everytime we fetch a brigade which seems
unintuitive. Should a apr_bucket_read() call on a bucket with e->length == 0 cause a 
seg
fault? Seems this check is masking a deeper problem.

Thoughts?
- Original Message -
From: "Adam Sussman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 01, 2002 9:35 PM
Subject: Re: [PATCH] mod_proxy infinite cpu eating loop


>
> Bill,
>
> Everything looks good except that ap_proxy_string_read() now segfaults on
> its apr_bucket_read().  It appears that APR_BRIGADE_EMPTY is not sufficient
> to detect the case of the closed socket with no data.  I suspect that this
> is because the core filter seeds the brigade with a socket bucket and that
> this is what is giving apr_bucket_read problems.
>
> This bit of code seems to do the trick, but again I am still a little unsure
> of my footing with filters and buckets.
>
> -adam
>
>
> Index: proxy_util.c
> ===
> RCS file: /home/cvspublic/httpd-2.0/modules/proxy/proxy_util.c,v
> retrieving revision 1.75
> diff -u -r1.75 proxy_util.c
> --- proxy_util.c 31 Dec 2001 20:43:59 - 1.75
> +++ proxy_util.c 2 Jan 2002 01:29:58 -
> @@ -1031,7 +1031,13 @@
>  if (APR_BUCKET_IS_EOS(e)) {
>  *eos = 1;
>  }
> +else if (e->length == 0) {
> +APR_BUCKET_REMOVE(e);
> +apr_bucket_destroy(e);
> +break;
> +}
>  else {
> +
>  if (APR_SUCCESS != apr_bucket_read(e, (const char **)&response, 
>&len,
APR_BLOCK_READ)) {
>  return rv;
>  }
>

Re: cvs commit: apache-1.3/src/os/netware ApacheCore.imp

2002-01-02 Thread Brad Nicholes


Rebuilt and tested Apache for NetWare with the changes and everythings
seems to checkout so far.  Just off hand I don't see anything that will
cause us a problem.

>>> [EMAIL PROTECTED] Thursday, December 27, 2001 10:48:54 PM >>>
Applied, but this needs to be double-checked on Netware.

> wrowe   01/12/27 21:03:08
> 
>   Modified:src  ApacheCore.def
>src/ap   ap_snprintf.c
>src/include ap.h ap_alloc.h buff.h
http_conf_globals.h
> http_config.h http_core.h http_log.h
http_main.h
> http_protocol.h http_request.h http_vhost.h
httpd.h
> rfc1413.h
>src/main alloc.c buff.c http_config.c http_core.c
http_log.c
> http_main.c http_protocol.c http_request.c
> http_vhost.c rfc1413.c util.c
>src/os/netware ApacheCore.imp
>   Log:
> Normalize symbol exports for Win32/Netware to the httpd.exp
reference.
> Diff tags pre_win_nw_syms/post_win_nw_syms for complete edit.
>   
> Note I've corrected _SEVERAL_ badly declared symbols on Win32
into
> API_EXPORT_NONSTD flavors (e.g. those using (...) args).  This
may,
> or may not, break binary compatibility depending on how those
args
> are addressed, and if those functions were used.
>   
> I've further tested by setting aside the .def file and
rebuilding,
> and validated that our symbols list corresponds to the
API_DECLARE()
> macros at this moment.
>   
>   Submitted by: Thomas Eibner <[EMAIL PROTECTED]>
>   Reviewed by: Stoddard, Rowe


Here is the list of badly declared, now _NONSTD functions (with a list
like this,
I'm afraid much binary compatibility will be lost);

-API_EXPORT(int) ap_snprintf(char *buf, size_t len, const char
*format,...)
+API_EXPORT_NONSTD(int) ap_snprintf(char *buf, size_t len, const char
*format,...)

-API_EXPORT(void) ap_table_do(int (*comp) (void *, const char *, const
char *), void *rec,
- const table *t,...);
+API_EXPORT_NONSTD(void) ap_table_do(int (*comp) (void *, const char *,
const char *), 
+void *rec, const table *t,...);

-API_EXPORT(int) ap_bvputs(BUFF *fb,...);
+API_EXPORT_NONSTD(int) ap_bvputs(BUFF *fb,...);

-API_EXPORT(int) ap_rprintf(request_rec *r, const char *fmt,...)
+API_EXPORT_NONSTD(int) ap_rprintf(request_rec *r, const char
*fmt,...)

-API_EXPORT(void) ap_log_error(const char *file, int line, int level,
+API_EXPORT_NONSTD(void) ap_log_error(const char *file, int line, int
level,
 const server_rec *s, const char *fmt, ...)

-API_EXPORT(void) ap_log_rerror(const char *file, int line, int level,
+API_EXPORT_NONSTD(void) ap_log_rerror(const char *file, int line, int
level,
 const request_rec *s, const char *fmt, ...)

-API_EXPORT(void) ap_log_printf(const server_rec *s, const char *fmt,
...)
+API_EXPORT_NONSTD(void) ap_log_printf(const server_rec *s, const char
*fmt, ...)


And finally, here is a list of the differences remaining between
httpd.exp and the
win32 exported symbols.  I'm posting the list mostly because someone
might want to
go back over httpd.exp, since some win32 inclusions should fall in the
httpd.exp
list.  Also, there are a few more missing symbols in the win32 list yet
to be fixed.

--- httpd.exp Thu Dec 27 23:07:54 2001
+++ declared.ref Thu Dec 27 23:45:46 2001
+access_module
+alias_module
+ap_acquire_mutex
+ap_add_loaded_module
+ap_bpushh
+ap_check_alarm
-ap_child_terminate
+ap_create_mutex
+ap_destroy_mutex
-ap_dummy_mutex
+ap_get_limit_req_body
+ap_get_service_key
+ap_get_win32_interpreter
-ap_listeners
+ap_loaded_modules
+ap_md5_binary
+ap_note_cleanups_for_h
+ap_open_mutex
+ap_os_canonical_filename
+ap_os_case_canonical_filename
+ap_os_dso_error
+ap_os_dso_load
-ap_os_is_path_absolute
+ap_os_is_filename_valid
+ap_os_systemcase_filename
+ap_pcloseh
-ap_prelinked_modules
-ap_preloaded_modules
-ap_register_other_child
+ap_registry_get_server_root
+ap_release_mutex
+ap_remove_loaded_module
-ap_rfc1413_timeout
+ap_scan_script_header_err_core
-ap_signal
-ap_slack
-ap_sys_siglist
-ap_unregister_other_child
-ap_util_init
-ap_util_uri_init
+ap_uuencode
+apache_main
+asis_module
+auth_module
+autoindex_module
+cgi_module
+closedir
+config_log_module
+dir_module
+env_module
+imap_module
+includes_module
+mime_module
+negotiation_module
+opendir
+os_spawnle
+os_spawnv
+os_spawnve
+os_stat
+os_strftime
+readdir
+regcomp
+regerror
+regexec
+regfree
+setenvif_module
+so_module
-XML_DefaultCurrent
-XML_ErrorString
-XML_ExternalEntityParserCreate
-XML_GetBase
-XML_GetBuffer
-XML_GetCurrentByteCount
-XML_GetCurrentByteIndex
-XML_GetCurrentColumnNumber
-XML_GetCurrentLineNumber
-XML_GetErrorCode
-XML_GetSpecifiedAttributeCount
-XML_Parse
-XML_ParseBuffer
-XML_ParserCreate
-XML_ParserCreateNS
-XML_ParserFree
-XML_SetBase
-XML_SetCdataSectionHandler
-XML_SetCharacterDataHandler
-XML_SetCommentHandler
-XML_SetDefaultHandler
-XML_SetDefaultHandler

Re: cvs commit: httpd-2.0 STATUS

2002-01-02 Thread David Reid


> On Wed, Jan 02, 2002 at 08:13:33AM -, [EMAIL PROTECTED] wrote:
> ...
> >  lost.  This might be an APR issue with how it deals with
> >  the child_init hook (i.e. the fcntl lock needs to be resynced).
> >  More examination and analysis is required.
> >   +
> >   +  Status: This has also been reported on Cygwin.
> >   +
> >   +  Message-ID: <[EMAIL PROTECTED]> (cygnus)
> >   +
> >   +  Justin says: So, FreeBSD-CURRENT and Cywin have the same
> >   +   problem.  Yum.  If another platform has this
> >   +   with worker, this becomes a showstopper.
>
> Do either platforms pass the tests in APR (testthread, etc)?

Can we try and specify EXACTLY what the problem is? We probably need to try
and write some tests that expose it so we can debug further. Given how many
people will want to use FreeBSD we should probably try hard to find/fix
this!

> I can't seem to get my [recently updated 5.0-CURRENT] FreeBSD box
> to compile anything except the prefork MPM, no matter what I do,
> but I must be doing something wrong. Am I the only one with this
> weird problem?

I think Justin was right about using --enable-threads

david

Re: setsockopt error

2002-01-02 Thread Jeff Trawick


"Don Hughes" <[EMAIL PROTECTED]> writes:

> Apache2.0
> 
> If all of my vhosts are of the form:
> 
> 
> 
> and if there is a Listen for a port (81)  that does NOT appear in a VirtualHost 
> directive, then I get:
> 
> ... [crit] (88)Socket operation on non-socket: make_sock: for address [::]:81, 
> setsockopt: (SO_REUSEADDR)

I just hit the same error but for a different scenario.  I changed the
port number on my single Listen statement and then did apachectl
restart.
-- 
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
   http://www.geocities.com/SiliconValley/Park/9289/
 Born in Roswell... married an alien...

Invalid expression "$REDIRECT_URL = //$/"...

2002-01-02 Thread Jeff Trawick


What's up with this?

[Wed Jan 02 10:38:14 2002] [error] [client 9.27.56.230] Invalid
expression "$REDIRECT_URL = //$/" in file
/usr/local/apache2/error/HTTP_FORBIDDEN.html.var, referer: 
http://trawick.raleigh.ibm.com:8080/

-- 
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
   http://www.geocities.com/SiliconValley/Park/9289/
 Born in Roswell... married an alien...

GNU build of Apache 2.0 for NetWare - httpd fixes (2)

2002-01-02 Thread Pavel Novy


Brad,
here are additional changes in the sources needed to build Apache's 
binaries for NetWare with the GNU tools.

config.c.patch, listen.c.patch and protocol.c.patch - Uninitialized 
variables changed to initialized, so now they can be exported by 
Apache's core NLM if linked by a nlmconv utility.

mod_rewrite.c.patch - Module functionality untested, but it's possible 
to compile with LIBC and the GNU tools. Not sure if you already tried to 
compile 2.0 version of this module with CodeWarrior...

Thanks,
Pavel


--- original/server/config.cFri Dec 14 06:12:15 2001
+++ modified/server/config.cSat Dec 22 21:45:43 2001
@@ -95,13 +95,13 @@
 #include "mpm.h"
 
 
-AP_DECLARE_DATA const char *ap_server_argv0;
+AP_DECLARE_DATA const char *ap_server_argv0 = NULL;
 
 AP_DECLARE_DATA const char *ap_server_root = NULL;
 
-AP_DECLARE_DATA apr_array_header_t *ap_server_pre_read_config;
-AP_DECLARE_DATA apr_array_header_t *ap_server_post_read_config;
-AP_DECLARE_DATA apr_array_header_t *ap_server_config_defines;
+AP_DECLARE_DATA apr_array_header_t *ap_server_pre_read_config = NULL;
+AP_DECLARE_DATA apr_array_header_t *ap_server_post_read_config = NULL;
+AP_DECLARE_DATA apr_array_header_t *ap_server_config_defines = NULL;
 
 AP_DECLARE_DATA ap_directive_t *ap_conftree = NULL;
 


--- original/server/listen.cSat Dec  8 06:12:13 2001
+++ modified/server/listen.cSat Dec 22 21:46:53 2001
@@ -72,7 +72,7 @@
 #include "mpm.h"
 #include "mpm_common.h"
 
-ap_listen_rec *ap_listeners;
+ap_listen_rec *ap_listeners = NULL;
 #if APR_HAVE_IPV6
 static int default_family = APR_UNSPEC;
 #else


--- original/server/protocol.c  Fri Dec 21 06:12:22 2001
+++ modified/server/protocol.c  Sat Dec 22 21:41:26 2001
@@ -104,7 +104,7 @@
APR_HOOK_LINK(default_port)
 )
 
-AP_DECLARE_DATA ap_filter_rec_t *ap_old_write_func;
+AP_DECLARE_DATA ap_filter_rec_t *ap_old_write_func = NULL;
 
 /*
  * Builds the content-type that should be sent to the client from the


--- original/modules/mappers/mod_rewrite.c  Sun Dec 30 06:12:16 2001
+++ modified/modules/mappers/mod_rewrite.c  Wed Jan  2 13:34:00 2002
@@ -114,7 +114,7 @@
 #include "http_protocol.h"
 #include "mod_rewrite.h"
 
-#if !defined(OS2) && !defined(WIN32) && !defined(BEOS)
+#if !defined(OS2) && !defined(WIN32) && !defined(BEOS) && !defined(NETWARE)
 #include "unixd.h"
 #endif
 
@@ -4154,12 +4154,14 @@
 **
 */
 
+/*
 #ifdef NETWARE
 int main(int argc, char *argv[]) 
 {
 ExitThread(TSR_THREAD, 0);
 }
 #endif
+*/
 
 /* the apr_table_t of commands we provide */
 static const command_rec command_table[] = {

[PATCH] 1.3: further Cygwin platform support

2002-01-02 Thread Stipe Tolj


I have added a couple of changes to the Cygwin 1.x platform support
for the 1.3 branch. First of all this diff is against a recent cvs
tree. The patch applies cleanly to the current cvs tree.

What's new:

  * Supports now --enable-shared=max option for configure, which is
also used in src/helpers/binbuild.sh for the binary distribution. This
solves especially the mod_proxy compilation problem we had previosly.

  * Cygwin now has an additional configure rule CYGWIN_WINSOCK, which
enables to use Win32 native calls for the socket calls instead of
using POSIX.1 wrappers by the Cygwin emulation layer itself. This is
an performance gain of about 5-10%. Therefore we had to add a couple
of define statements in src/main/buff.c.

  * For accept mutexes we used previously fctnl, which seems to have a
cerious problem when using more then one Listen directive in
httpd.conf. Apache starts and serves on any port specified by Listen,
but does not shut down. Even using the Win32 task manager to kill the
parent httpd process did not suceed. We now use pthread as default
accept mutex mechanism, which works without any known problems.

  * Added #define wrapper for the timeout signal too, that is
different for Cygwin that for other Unixes to be more drastic on this
platform. We still encounter Keep-Alive hanging childs that do not go
away in the timeout limit. This seems to be a Cygwin OS layer problem,
still investigating.


The patch has been created with impact for other platforms in mind. So
there are no changes in behaviour for other OSs.

Here are the changes in the current 1.3 cvs tree:

  * src/Configuration.tmpl: added Rule CYGWIN_WINSOCK for Win32 native
socket support.
  * src/Configure: added checking for RULE_CYGWIN_WINSOCK in the
Cygwin case block. Changed OS_MODULE_INCLUDE to use the full
(relative) path, so we can find the additional Makefile in other
source directories too (i.e proxy).
  * src/helpers/binbuild.sh: Added pre-defined MAKERUN statement
(suggested by Martin) to make env safe. Cygwin needs to re-run "make"
due to the fact that linking shared modules requires to have the
shared core DLL present, which is in fact linked at the end.
  * src/helpers/install.sh: add .exe extension for executables on
Cygwin. Martin, this should be a satisfying solution and should work
for any OS (if any would use the script and .exe extensions)?!
  * src/include/ap_config.h: changed default to
USE_PTHREAD_SERIALIZED_ACCEPT.
  * src/main/buff.c: added #defines to include native Win32 socket
calls if CYGWIN_WINSOCK rule is used.
  * src/main/http_main.c: exluded pthread_mutexattr_setpshared() call
for Cygwin, which seems to have OS specific problems. Added aditional
#defines for CYGWIN_WINSOCK. Added wrapper #define SIG_TIMEOUT_KILL to
handle which signal is used for timeout shutdowns of the childs.
  * src/modules/proxy/Makefile.tmpl: the libproxy.dll Makefile rule
has been hard-coded for OS/2, which is not a good idea, Cygwin
produces also a libproxy.dll version, but with other tools, so we have
to introduce an if statement here to see on which OS we are.
  * src/modules/standard/Makefile.Cygwin: added an "empty" rule to
satisfy OS/2 specific dependancies. This won't hurt the build process.
Removing the shared core import library if existing to update
everything inside and use a dummy file to indicate if the re-run
warning has to be displayed. It should be displayed only once, in
order to not annoy the user.
  * src/os/cygwin/os.h: added necessary declarations for the
CYGWIN_WINSOCK rule.


Can someone, maybe Martin and Lars review the code and commit to cvs,
please?!


Stipe

[EMAIL PROTECTED]
---
Wapme Systems AG

Münsterstr. 248
40470 Düsseldorf

Tel: +49-211-74845-0
Fax: +49-211-74845-299

E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
---
wapme.net - wherever you are

diff -ur apache-1.3/src/Configuration.tmpl apache-1.3-cygwin/src/Configuration.tmpl
--- apache-1.3/src/Configuration.tmpl   Mon Oct  8 17:52:12 2001
+++ apache-1.3-cygwin/src/Configuration.tmplSat Nov 10 16:48:46 2001
@@ -173,6 +173,13 @@
 #  Rule EXPAT=default   : If Expat can be found at the system or
 # in lib/expat-lite, use it; otherwise
 # skip it
+# 
+# CYGWIN_WINSOCK: 
+#  Use Win32 API system calls for socket communication instead 
+#  of Cygwin's POSIX.1 wrappers. This avoids the Cygwin specific
+#  implementation and uses the Win32 native calls. Should be faster
+#  and more reliable for high-load systems.  
+# 
 
 Rule SOCKS4=no
 Rule SOCKS5=no
@@ -180,6 +187,7 @@
 Rule IRIXN32=yes
 Rule PARANOID=no
 Rule EXPAT=default
+Rule CYGWIN_WINSOCK=no 
 
 # DEV_RANDOM:
 #  Note: this rule is only used when compiling mod_auth_digest.
diff -ur apache-1.3/src/Configure apache-1.3-cygwin/src/Configure
--- apache-1.3/src/ConfigureMon Oct  8 20:59:36 200

Re: cvs commit: httpd-2.0 STATUS

2002-01-02 Thread Justin Erenkrantz

On Wed, Jan 02, 2002 at 01:03:29AM -0800, Aaron Bannert wrote:
> Do either platforms pass the tests in APR (testthread, etc)?

FreeBSD-CURRENT passes sendfile, testthread and testlockperf.
Any others?

> I can't seem to get my [recently updated 5.0-CURRENT] FreeBSD box
> to compile anything except the prefork MPM, no matter what I do,
> but I must be doing something wrong. Am I the only one with this
> weird problem?

OH!  You forgot to pass --enable-threads to configure - we still
have an override in APR to disable threads on FreeBSD.  Sounds 
like httpd should be erroring out when we can't get a specified 
MPM (assuming you are using --with-mpm=worker).  I thought
we did error out...  -- justin

Re: cvs commit: httpd-2.0 STATUS

2002-01-02 Thread Aaron Bannert


On Wed, Jan 02, 2002 at 08:13:33AM -, [EMAIL PROTECTED] wrote:
...
>  lost.  This might be an APR issue with how it deals with
>  the child_init hook (i.e. the fcntl lock needs to be resynced).
>  More examination and analysis is required.
>   +
>   +  Status: This has also been reported on Cygwin.  
>   +
>   +  Message-ID: <[EMAIL PROTECTED]> (cygnus)
>   +
>   +  Justin says: So, FreeBSD-CURRENT and Cywin have the same 
>   +   problem.  Yum.  If another platform has this
>   +   with worker, this becomes a showstopper.

Do either platforms pass the tests in APR (testthread, etc)?

I can't seem to get my [recently updated 5.0-CURRENT] FreeBSD box
to compile anything except the prefork MPM, no matter what I do,
but I must be doing something wrong. Am I the only one with this
weird problem?

>* There is increasing demand from module writers for an API
>  that will allow them to control the server à la apachectl.

-aaron

Re: cvs commit: httpd-2.0/server core.c

2002-01-02 Thread Justin Erenkrantz

On Wed, Jan 02, 2002 at 07:56:25AM -, [EMAIL PROTECTED] wrote:
> jerenkrantz02/01/01 23:56:25
> 
>   Modified:.CHANGES
>include  http_core.h
>modules/http http_protocol.c
>server   core.c

Note that HTTP_IN now calls ap_die on an limit error condition.  Is 
this correct?  I think this is wonky, but ap_get_client_block 
neglects the error code, so it gets lost if HTTP_IN were to return 
HTTP_REQUEST_ENTITY_TOO_LARGE.  The only true way for this to be 
returned to the caller is to change the prototype of 
ap_get_client_block or throw out that function entirely (and force 
everyone to use buckets directly - which I believe is the way to 
go anyway).  Yet, this may not be possible in the 2.0 timeframe.

If we want to change the ap_get_client_block prototype in the 2.0
timeframe, I'd suggest holding up 2.0.30 so that this API gets in.
This and the ap_getline/input-filtering API changes makes me want
to hold up a beta so that we can get the APIs straightened out.  Or,
we should open up 2.1 with these API changes...  -- justin

53 matches

Mail list logo