us ironing these issues out before the release, lest we have to deal with
another month's worth of duplicates of the same three PR's like we have with
the last two releases.  :)

Also demoting the server-pushed CGI thing to not-a-showstopper since there
has been zero to virtually zero talk about it since I added it to the
showstoppers list.


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

Submitted by:	Stas Bekman <stas@stason.org>
Reviewed by:	Heinrich G�tzger <goetzger@gmx.net>, Cliff Woolley


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

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

Submitted by: Jean-Jacques Clar


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

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

  Solve the -k start bug [thanks for the pointers, FirstBill!]

  The answer was really trivial.  Unlike all other cases where you
  expect to send argv[0] and get argv[0] in the created process,
  the service control manager (SCM) just don't work like that.

  StartService() argv passed must not include an element zero.
  Element zero is inserted by the SCM, containing the service name,
  without any help from the outside.

  Only reason this bug 'appeared' is that Jeff's patch introduced
  a bit of strictness to refuse arguments without a flag.


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

  Potential fixes.  Patch up the fact that users often expect argv[]s
  to be NULL terminated, even though argc should clearly limit the array.


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

  cvs up/diff gets pretty hard to track with vc7 builds.


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

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

besides server-root/build.

PR:           8453

Submitted by: a number of people hit this problem and offered hints or
              partial fixes; Thom May and Pier Fumagalli had a patch to
              apxs, a subset of which mostly fixed this problem; there
              were hints in PRs 8453 and 9316


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

When deflating: only reset ctx->stream buffers when the ctx was NULL.
When inflating: remember to clear the ctx->bb after we're done with it.


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

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

mod_disk_cache still needs work.


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

/me crosses fingers


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

distribution in the hash table resulting in a 20% performance boost when
caching 6000+ files in a hash table with 512 collision chains.

Submitted by: Jean-Jacques Clar <jjclar@novell.com>


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

DEFAULT_MAX_OBJECT_CNT (changed from 512)


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

mod_deflate


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

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

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

same request.  Essentially, ap_http_filter keeps track of whether
it has sent an EOS bucket up the stack, if so, it will only ever
send an EOS bucket for this request.

Submitted by:	Ryan Bloom, Justin Erenkrantz, Greg Stein


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

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

order.  It has been released after submitting to rehabilitation.
(No functional changes.)


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

redirecting (.*) will allow an SSL protected page to be viewed
without SSL.


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

Submitted by:	Hiroaki KAWAI <hawk@bcl.t.u-tokyo.ac.jp>
Reviewed by:	Yoshiki Hayashi


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

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

  Feedback appreciated - I'm guessing that we can trust the isapi app
  opened file handles correctly for the TransmitFile case.


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

  The only remaining question ... are nested or strictly unnested locks
  expected by OpenSSL?  Right now I've left it as _DEFAULT for the platform
  preference.  Very simple code really - the server_rec was superfluous.


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

add more status updates on the two biggies


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

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

even with no change, user can --disable-threads so I wonder if
this should really be a showstopper; it would be nice to get
feedback from the user on my patch


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

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

created by "apxs -g" will work when the user has a binary
build.

We didn't copy enough of the build directory and we edited
the wrong version of config_vars.mk.


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

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

"-L/path/to/lib after "-o target".  After looking into build failures,
it turned out that we specify EXTRA_LDFLAGS twice (once before "-o
target" and once after "-o target") for httpd and for the support
utilities.


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

(No functional changes.)


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

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

both me and Justin today.


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

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

This was an issue for APR/APR-Util, not httpd.


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

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