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

the module structures

add mod_vhost_alias.exp


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

built as DSOs


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

of the module structures


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

when SSL needs to flush (e.g. during SSL_accept()) it will call BIO_flush()
which will trigger a call to bio_bucket_ctrl() -> BIO_bucket_flush().
so we only need to flush the output ourselves if we receive an EOS or
FLUSH bucket.

BIO_bucket_flush() and churn_output() had been turning up near the top
of the profile with gprof.  churn_output() of course has now vanished
and BIO_bucket_flush() has dropped, being called far less than before.

PR:
Obtained from:
Submitted by:
Reviewed by:


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

ap_strchr(), ap_strchr_c(), et al so that for an AP_DEBUG build
of Apache those functions will be listed in httpd.exp...  otherwise,
AIX DSO modules also compiled with AP_DEBUG won't be able to resolve
those symbols since httpd isn't exporting them


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

(but to be honest I have no idea whether or not this path is
ever used... it seems quite bizarre)


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

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

this isn't the only one needed, but somebody needed this one...
I'll take a few minutes sometime soon and see which others we
need

Submitted by:	Dick Dunbar (RLDunbar@pacbell.net)


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

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

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

copy the lib/ directory when installing a binary.


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

  Ensure we include path_info in ap_internal_fast_redirect() for multiview
  mapping.  This isn't the end of these bugs, only one puzzle piece.


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

  Ingorance is bliss


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

have a DSO that goes through the load-unload-load cycle.

Suggested by:	Ryan Morgan <rmorgan@covalent.net>, Cliff Woolley


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92256 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

copy them for components), but each component has its own r->pool.
So once the first component set "Max-Forwards", it is in headers_in
but the value could get lost with the first component's r->pool.
Hence I sometimes see "Max-Forwards" has value like letter "l".
Change it to use apr_table_set() fixed the problem.

Submitted by:	Jin Hong <jinh@cnet.com>


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

also, pick up an edit I missed last time around...whoops!


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

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

  Finish undoing that last patch... previous commit simply cleaned it up,
  I was working with an unsaved verison when I pushed the button.


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

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

  Revert my last patch to detect a 'leftover' arg.  Apparently there is
  no way to distinguish between an extra arg, and a -x foo arg, or else
  our getopt is broken at the moment.

  I can't dig further into getopt right now, so this will wait for another
  day or another hacker to resolve.


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

  I don't believe it.  This actually fixes the rest of the type mismatches.

  Of course, I could have hosed everything, a second pair of eyes would be
  appreciated.


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

  We never tested for invalid 'additional' arguments that were ignored.
  Was there any point to allowing additional, unused args after the
  various supported switches?

  This prevents the Apache server from starting with an httpd somefooness
  invocation.


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

is happening.  so avoid calling that unless needed and just stash a
pointer to the client cert for the boolean checks that the client
provided a cert.
PR:
Obtained from:
Submitted by:
Reviewed by:


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92240 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

ssl_callback_SSLVerify_CRL() unless SSLLogLevel >= info, otherwise the
expense is unused.
PR:
Obtained from:
Submitted by:
Reviewed by:


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

what should be done with a macro.  it was only used once anyhow.
PR:
Obtained from:
Submitted by:
Reviewed by:


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

function and free() of the return value twice each, for logging
regardless of SSLLogLevel.  changed to happen only if SSLLogLevel >= trace
PR:
Obtained from:
Submitted by:
Reviewed by:


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

go back to using s->process->pool userdata, but just to store the
global module config during startup so we only create _one_ SSLModConfigRec.
(didn't realize this function was called in both ssl_init_Module and
ssl_config_server_create)
PR:
Obtained from:
Submitted by:
Reviewed by:


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

in the gprof profile.  there's no need for the "global" SSLModConfigRec
to live in the s->process->pool userdata table.  we now just point the
SSLSrvConfigRec in each server_rec.module_config to the SSLModConfigRec
so we can access it directly which is much faster.
PR:
Obtained from:
Submitted by:
Reviewed by:


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

two calls that seed pid and time into one.
PR:
Obtained from:
Submitted by:
Reviewed by:


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

this was being called twice per-connection with 'SSLRandom connect builtin'
configured (which is in the default config)

this also gets rid of two time() syscalls per-connection

PR:
Obtained from:
Submitted by:
Reviewed by:


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

to avoid getpid() calls at request time
PR:
Obtained from:
Submitted by:
Reviewed by:


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

PR:
Obtained from:
Submitted by:
Reviewed by:


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

Submitted by:	Ryan Morgan <rmorgan@covalent.net>
Reviewed by:	Aaron Bannert


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

to create install-bindist.sh


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

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92227 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@92225 13f79535-47bb-0310-9956-ffa450edef68