Resolved segfault in mod_isapi when configuring with ISAPICacheFile.

PR: 8563, 8919


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

directories that are not well known to the loader.

How it works:
* libtool figures out the name of this system's library path environment
  variable (i.e. LD_LIBRARY_PATH, LIBPATH, DYLD_LIBRARY_PATH) at apr
  configure time (existing code)
* save this variable name in SHLIBPATH_VAR in APRVARS
* substitute this name when apachectl is created
* uncomment the lines containing this variable during binbuild
* install_bindist.sh updates the path to lib/ when the binary is
  installed (existing code)

not done yet, but a good idea:
* create a file or directory containing all environment variable settings
  for apachectl.  Others env vars need to be tweaked, at least on AIX and
  OS/390, so keeping them separate should reduce headaches long term.


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

working on AIX.

Submitted by: a cast of many, reverse engineering libtool to
              figure out how to work around its oddities/limitations/
              bugs on AIX
              (Jeff Trawick coded these changes but it took a lot of
              help)


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

terminating "-->" is the last byte in a file (previously,
the output of the directive was lost in this case).


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

message that we had back in apache-1.3 and is still scattered throughout
our docs.

Unfortunately, when mod_suexec is a DSO we're going to get this thing
twice in our logs. I believe as a side effect of the load-unload-load
cycles of our DSOs we're losing the static data segment, which is where
the "didn't we already report this" flag lives.


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

  Prevent Apache from continuing to start when it's encountered a parsing
  error in the Win32 mpm's argv[] review.

  Reported by Grif Rosser <grifr@covalent.net>


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

This bit me when I included a 11th file no error message, nothing.


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

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

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

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

installed in the correct location.

PR:	8851
Submitted by:	Yoshifumi Hiramatsu <hiramatu@boreas.dti.ne.jp>
                and Gomez Henri <hgomez@slib.fr>


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

a cmd command, we do not want to use the r->filename to set
the command name.  The command comes from the SSI tag.  To do this,
I added a variable to the function that builds the command line
in mod_cgi.  This allows the include_cmd function to specify
the command line itself.

PR:	8772


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

while opening logs

Obtained from: Doug MacEachern


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

causing the server not to start.
previous method was to call exit(1) which would not fail
gracefully

PR:
Obtained from:
Submitted by:
Reviewed by:	(Idea only Jeff Trawick)


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

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

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

supports gzip transfer-encoding as an output filter.

Initially coded by Ian, but Justin made a number of improvements to
the coding style and its use of filters.

We have 7 binding +1s and no vetos in STATUS for addition.


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

Submitted by: jean-frederic clere <jfrederic.clere@fujitsu-siemens.com>
Reviewed by:  Jeff Trawick


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

PR:
Obtained from:
Submitted by:	John Sterling <sterling@covalent.net>
Reviewed by:	dougm


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

Committed with some minor changes.
Submitted by:	GOMEZ Henri <hgomez@slib.fr>
Reviewed by:	Justin Erenkrantz


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

There were a couple of bogus IPv4-specific comparisons which prevented
the data structures from being built correctly in ap_fini_vhost_config().
One of these (INADDR_ANY) can be easily rewritten to work with IPv6.  The
other (DEFAULT_VHOST_ADDR) isn't necessary for IPv6.  Note that this is
because we don't support the various flavors of _default_ that
Apache-1.3+KAME-patch supports.

PR:      8118


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

optimized away some pointer arithmetic in the inner loop of the BNDM string-search function in mod_include


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

PR: 8804
Submitted by:	Taketo Kabe <kabe@sra-tohoku.co.jp>, Cliff Woolley


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

The deletes come next.


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

in logging the error from a failed DNS lookup.

Note: For a funky error scenario to work right (huge host name),
this requires a tweak to apr_gethostname() which I have not yet
committed.


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

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

Presumably other such processes are affected to.  Now we
give main() a chance to clean up.


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

file, we use a sub-request, but we didn't destroy the sub-request
immediately, instead we waited until the original request was
done.  This patch closes the sub-request as soon as the data is
done being generated.

This passes all tests in the test suite.

Submitted by:	Brian Pane <bpane@pacbell.net>
Reviewed by:	Ryan Bloom and Cliff Woolley


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

define the function that should be used to accept on that
socket.  Each MPM can define their own function to use for
the accept function with the MPM_ACCEPT_FUNC macro.  This
also abstracts out all of the Unix accept error handling
logic, which has become out of synch across Unix MPMs.

The code flow is much easier now for different transports:

1)  During pre-config, post-config or while parsing the config
    file, add a socket to the ap_listeners list, making sure to
    define an accept function at the same time.

2)  MPMs find the correct listener, and call the accept function
    that was defined in step 1.

3)  That accept function returns a void pointer, which is passed
    to the create_connection hook.

4)  create_connection adds the correct low-level filters.


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

when sending a negotiated ErrorDocument because the required
filters were attached to the wrong request_rec.

Submitted by:	John Sterling <sterling@covalent.net>
Reviewed by:	Justin Erenkrantz, Cliff Woolley


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

carried away and rewrote half the paragraph.  <sigh>


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

directives that are used by MPMs.  Previous to this patch,
you would use these macros without commans, which was unlike
any other directives. Now, after the macro, you must have
a comma.  This makes the macros look more like the rest of the
directives.

I know this is cosmetic, and I was going to leave it alone, but when
I found out that it bothered Cliff too, I decided to fix it after all.

Submitted by:	Ryan Bloom and Cliff Woolley


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

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

The first step is to remove the socket from the conn_rec,
the server now lives in a context that is passed to the
core's input and output filters. This forces us to be very
careful when adding calls that use the socket directly,
because the socket isn't available in most locations.


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

of the number of threads per process.


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

configured value is not a multiple of the number of threads
per child.  We said we did previously but we forgot to.


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

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

will be restored soon.


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

APR_SUCCESS when it reads something (which is 0).

Two of the cases were doing while apr_file_gets > 0 which would cause
it to loop when it returned APR_EOF.  So, the valid check here is to
loop while we are receiving APR_SUCCESS.

Fix all of the other apr_file_gets to check APR_SUCCESS explicitly so
that it is obvious that we are checking an apr_status_t.  Yes,
0 == APR_SUCCESS, but it obviously wasn't clear to someone what it
was returning.

Submitted by:	Dale Ghent <daleg@elemental.org>,
                Brian Pane <bpane@pacbell.net>
Reviewed by:	Justin Erenkrantz


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

Submitted by:	Daniel Stone <daniel@sfarc.net>
Reviewed by:	Justin Erenkrantz


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