the request's pool, rather than copying into a caller-supplied
buffer.  (This lets us eliminate one copy operation on the
request headers.)


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

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

ap_escape_html() to eliminate a redundant scan through the string.


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

SSI tags to lowercase when they're already lowercase (in my
experience, this special case happens often enough to be
worth optimizing)


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

where the string being decoded doesn't have any ampersands
in it (e.g., because it's the value for an 'include virtual=...')


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

strings passed to apr_hash_get/apr_hash_set (this matches
the convention used throughout the rest of the httpd,
and it saves a small amount of processing)


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

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

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

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

  Correct case comparison typematch


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

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