Introduced -E startup_logfile_name option to httpd to allow admins
     to begin logging errors immediately.  This provides Win32 users
     an alternative to sending startup errors to the event viewer, and
     allows other daemon tool authors an alternative to logging to stderr.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94681 13f79535-47bb-0310-9956-ffa450edef68

during graceless termination the cleanups on pchild won't mess with
stuff they are still referencing


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94679 13f79535-47bb-0310-9956-ffa450edef68

moving sooner by sending a SIGHUP to the accept thread, breaking it out
of its accept/poll.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94678 13f79535-47bb-0310-9956-ffa450edef68

Submitted by:	Stas Bekman
Reviewed by:	Jeff Trawick


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94677 13f79535-47bb-0310-9956-ffa450edef68

If we do not know a C-T for a subreq, we *must* propogate that
non-knowledge upwards to the main request.

Previously, if you used a DirectoryIndex with a file without a C-T (say
.shtml without AddType), the r->content_type will be kept as
httpd/unix-directory when we promoted the subreq in mod_dir.  Since there
would be no handler on this file, ap_invoke_handler (config.c:355) would
set the handler to be httpd/unix-directory (which was the old C-T of the
dir).  This would then trigger the handler to become httpd/unix-directory.
mod_autoindex would then try to serve the request.  But, the filename
was propogated upwards by mod_dir's DirectoryIndex via
internal_fast_redirect - it would then return a 403 trying to generate a
mod_autoindex page for a file.

Now, we will use ap_default_type() which is correct.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94676 13f79535-47bb-0310-9956-ffa450edef68

  Tired of 'foo.h not found' messages in the build.  Checked ms's docs,
  seems xcopy's /y arg goes all the way back to Win95.  This shouldn't
  introduce any hassles.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94675 13f79535-47bb-0310-9956-ffa450edef68

While this message will scroll by without their reading it, we can
reasonably say that we warned them if they report errors.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94674 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94673 13f79535-47bb-0310-9956-ffa450edef68

The threadpool MPM implements Aaron Bannert's "time-space tradeoff"
design managing idle workers.  Rather than putting accepted connections
into a queue, the threadpool MPM keeps idle worker threads in a stack.
Its dedicated listener thread retrieves an idle worker from the stack
before accepting a connection.  If there are no idle workers, the
listener blocks until a worker becomes available before doing an accept.

In many ways, threadpool is also a variant of leader/follower.  They
both maintain a stack of idle threads.  The difference is that threadpool
has a dedicated listener thread, and leader/follower rotates the listening
responsibility among its worker threads.  In my initial testing, the
leader/follower MPM performs very well on multiprocessor Solaris 8 when
listening on a single port, but poorly when listening on multiple ports.
(I don't know why this is happening.  What I've found so far is that
when you add a poll on the listen socket(s) before the accept in the
leader/follower MPM, all the socket-related syscalls in the httpd get
slower.  My hypothesis is that the thread scheduler is making an optimal
decision about where (on what CPU) to run the newly awakened thread if
its first syscall is an accept, and a nonoptimal decision if its first
syscall is a poll.)  The threadpool MPM performs better with multiple
listener ports, and in my testing so far it looks competitive with
leader/follower when running with a single listener.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94672 13f79535-47bb-0310-9956-ffa450edef68

config.guess/config.sub files to be identical.  Previously, we had three
different versions of the guess files - now they are the same.

I attempted to merge in ASF changes that were marked and still needed.
Please verify that these work on your platform.  (Particular attention
is required for the IBM platforms.)

Part of PR 7818 stems from the fact that the bundled expat did not have an
included config.guess/config.sub.  Therefore, it would take the config.guess
from the system.  Icarus's autoconf/libtool is very old (2.13/1.3.5).  The
machine that was used to roll 2.0.32 had a recent autoconf/libtool which
explains the behavior that Sander saw in the PR.  Therefore, we now
explicitly provide a config.guess/.sub for the bundled expat so that
all of the versions are in sync.  This should minimize configuration
problems.

pcre was using a config.guess that was imported when Brian made the 3.9
import.  It did not have the Apache modifications, but seems to have
had the Darwin changes.  Go figure.  Sync it up as well.

PR: 7818
Obtained from: GNU FSF - ftp.gnu.org/gnu/config


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94671 13f79535-47bb-0310-9956-ffa450edef68

ever since this was copy-and-pasted from the threaded MPM documentation,
and threaded *was* the default at one point.]

Reported by: kap@katchoo.org


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94670 13f79535-47bb-0310-9956-ffa450edef68

(Change 1.3->2.0)


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94669 13f79535-47bb-0310-9956-ffa450edef68

are guaranteed to support 100 - Continue logic without any
intervention.

This requires some reshuffling of the code in http_protocol.c so
that some static declarations are available early enough in the
code so that ap_http_filter can access them.

Note that we can not read the chunk until after (possibly) sending the
100.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94668 13f79535-47bb-0310-9956-ffa450edef68

to ap_get_mime_headers and calling it in the appropriate place in
ap_http_filter.

showstoppers--;


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94667 13f79535-47bb-0310-9956-ffa450edef68

wake up the next one in the list


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94666 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94664 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94663 13f79535-47bb-0310-9956-ffa450edef68

The equivalent logic was deleted when request filters were renamed to
RESOURCE filters.  This fixes the seg faults that sometimes happen on
daedalus after a bogus 416 HTTP response is generated.

In this case, includes_filter had found an <!--#include virtual > tag, and
sent a brigade representing the data before it down the filter chain.  The
byterange filter generated the bogus 416.  ap_send_error_response essentially
starts over with a new response, but it didn't do anything to clean up the
filter chain.  So the same instance of the includes_filter got driven from the
top with the canned error text and and EOS bucket, which confused the heck
out of it.  It inserted a sentinel from the original brigade into the
error page brigade, causing problems further down the filter chain.

Submitted by:	Greg Ames, Jeff Trawick


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94662 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94661 13f79535-47bb-0310-9956-ffa450edef68

message to force the module to unload.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94660 13f79535-47bb-0310-9956-ffa450edef68

small corrections to get us building again.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94659 13f79535-47bb-0310-9956-ffa450edef68

listed in CHANGES (IMHO).

I meant to include this with the vhost.c commit.
I am not doing good with commits today.  Grr.

PR: 7441


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94656 13f79535-47bb-0310-9956-ffa450edef68

Previously, request that sent:

GET / HTTP/1.1
Host:

would get a 400.  RFC 2616 specifically allows for a "blank" host field.

The read_request code properly handled this, but the fix_hostname in
vhost.c would cause the 400.  Now, simply return in fix_hostname when
we see a blank hostname rather than erroring out.

PR: 7441


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94655 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94654 13f79535-47bb-0310-9956-ffa450edef68

We install $(PROGRAMS) into $(sbindir) not $(bindir), so this is correct.

PR: 7840
Submitted by:	Andreas Hasenack <andreas@netbank.com.br>
Reviewed by:	Justin Erenkrantz


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94653 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94652 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94651 13f79535-47bb-0310-9956-ffa450edef68

PR: 7832
Submitted by: sn@neopoly.com (Sven Neuhaus)


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94649 13f79535-47bb-0310-9956-ffa450edef68

PR: 8037


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94648 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94646 13f79535-47bb-0310-9956-ffa450edef68

See:
http://www.iana.org/assignments/media-types/application/
http://www.rfc-editor.org/rfc/rfc3236.txt
http://www.iana.org/assignments/media-types/image/vnd.djvu

PR: 7795,7969


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94645 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94643 13f79535-47bb-0310-9956-ffa450edef68

the child process from a descriptor passed from the parent. This fixed vhost
address matching.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94642 13f79535-47bb-0310-9956-ffa450edef68

apr_bucket_alloc_destroy(). Don't double free by calling it explicitly.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94641 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94640 13f79535-47bb-0310-9956-ffa450edef68

  Respect the process_cgi argument


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94639 13f79535-47bb-0310-9956-ffa450edef68

  process_cgi is more descriptive than replace_cmd.

  It also affects query_string args.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94638 13f79535-47bb-0310-9956-ffa450edef68

  The fix requires a bump


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94637 13f79535-47bb-0310-9956-ffa450edef68

  If we have a registry command or a shebang line invocation, correct the
  invocation type to APR_PROGRAM_PATH so we will both search the path, and
  accept undecorated names, e.g. "perl" should be acceptable for "perl.exe".


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94636 13f79535-47bb-0310-9956-ffa450edef68

  Wasted at least 20 minutes reparsing this code till I determined it's
  correct.  But make the sucker legible so noone else repeats the experience.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94635 13f79535-47bb-0310-9956-ffa450edef68