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

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

containing any bucket that cannot be copied natively (ie, pipe or socket
buckets).

Before, we were reading that bucket to morph it to a heap bucket and then
taking the str that heap bucket points to and placing it in a second,
completely separate heap bucket.  That means we'd have two apr_bucket/
apr_bucket_heap pairs each with a refcount of 1 (rather than two apr_buckets
and a single apr_bucket_heap with a refcount of 2).  str would then be
doubly-freed when the second of those two buckets was destroyed.


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

  sec, sec, who's got a sec?  This gave me a headache, but I had to clear
  out the last patch before I rearranged this to be _readable_.

  Next step for everyone's sanity, provide <Proxy > directives ;)


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

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

  Commit this code before another patch becomes to difficult to follow.

  This patch does one thing, it changes the root path "/" to reflect an
  element count of Zero (0).  directory_walk will always accept the zero
  element (which sorts first, thankfully) on it's first go around.

  So, Unix will accept "/" when it's parsing it's first element "/".

  Dos/Win32 will accept "/" and "C:/" when they parse their first element,
  "C:/".  The root sorted first, so it behaves as users expect.

  The syntax "//" or "//machine" will be depreciated for now, the user
  needs to set up the extact "//machine/share/" that they want served
  on Win32.


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

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

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

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

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

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

request pool.


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

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

cleans up some race conditions, and gets the worker using
pools more cleanly.

Submitted by:	[Aaron Bannert <aaron@clove.org>]


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

allow it to be enabled

don't segfault if we don't have/need a lock

clear up several compile warnings


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

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

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

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

Submitted by:	Rich Bowen


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

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

have a chance to get APR ungetc working properly on buffered
files


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

of strchr()


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

apr optional functions do not need to be unregistered
PR:
Obtained from:
Submitted by:
Reviewed by:


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

"INTERNALLY GENERATED file-relative req"

PR:
Obtained from:
Submitted by:
Reviewed by:


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

PR:
Obtained from:
Submitted by:    Justin Erenkrantz <jerenkrantz@ebuilt.com>
Reviewed by:


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

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

PR:
Obtained from:
Submitted by:	Madhusudan Mathihalli <madhusudan_mathihalli@hp.com>
Reviewed by:	dougm


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

PR:
Obtained from:
Submitted by:	Justin Erenkrantz <jerenkrantz@ebuilt.com>
Reviewed by:


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

the real fix.  No functional change.


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

get rid of some warnings introduced by the original patch
PR:
Obtained from:
Submitted by:
Reviewed by:


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

  Add the config of the ForceLanguagePriority directive, since we seem
  to agree on what it does.  My last question is where do I force this
  behavior without tons of extra filesystem/cpu consumption?


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

PR:
Obtained from:
Submitted by:	Madhusudan Mathihalli <madhusudan_mathihalli@hp.com>
Reviewed by:	dougm


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

  Will I ever get my str*cmp semantics right?  Not at this hour...


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

  My initial changes failed to accomodate this faux entry.
  If you didn't see any <Directory > blocks working right, try
  this cvs update.


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

time

note that a system trace of .var map processing still shows an
extra read() after we hit EOF the first time; we could make
use of the EOF flag in APR to avoid the read() or play with
mod_negotiation

Suggested by:	Marc Slemko


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

  This flag is no more


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

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

  Revert this patch.  It indicates some fundamental brokenness with the
  apr_filepath_root() fn, which should simply return '/' for an absolute
  path on (most) unix, and advance the path pointer to the first non-'/'
  character  [if only Win32 and others were so simple ;-]


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

work better right now.  httpd-test is much much happier with this patch
(ie, we can serve pages again :)  I'm still seeing issues with mod_include,
but that's probably a different problem... will investigate.

Submitted by:	Doug MacEachern


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

  I'm still not 100% certain on this test.  Regardless, it doesn't impact
  Unix, and this was the bug that Jeff's (none the less correct) fix masked.


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