Adds quick access to the must-haves (STATUS/CHANGES) and group the apr
  library in to functional units


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

auto-computed string-length hash keys


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

  Some issues with the dependencies that prevent a clean checkout from
  actually building under win32


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

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

  This is a pretty significant cleanup of things already moved to OS2's
  APR - Brian, please review closely.


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

  Cleanup ap_os_kill from TPF and unix.  Maintainers please validate.


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

  Just some symbol cleanup from grep'ping sources.
  BS2000 maintainer please verify.


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

  Eliminating a bunch-o-junk from the Win32 os.h header that now lives
  in apr or isn't used.  Please review closely (every symbol removed was
  grep't for, and no references were found.)


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

a pointer to a static structure.  The ap_foo_type functions have also been
replaced with simple macro calls.  I am going to replace the
ap_bucket_(read|split|setaside|destroy) functions with macros soon.
Reviewed by:	Will Rowe


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

support concurrency levels > 1 against the loopback on BONE and will
actually use all the connections it starts.


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

  Change to buckets for isapi output.  Still requires emulation of IO
  Completion/Async behavior, but a non-async REQ_HSE_TRANSMIT_FILE is
  now implemented.


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

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

doesn't actually do anything useful, it was meant to remove all zero
length buckets before trying to read from the brigade.  However, it is
perfectly fine to not do this, and to just read those buckets along with
the rest of them.


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

missing some major pieces that I only found after the commit.  This patch
fixes the problem, and makes sure that request bodies are always ended
with an EOS bucket.


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

basic design has ap_setup_client_block setting a field in the conn_rec
which tells http_filter how much data is in the body (with chunking this
will represent how much data is in the chunk).  The ap_get_client_block
then calls down the stack with the maximum amount of data that it can
receive back.  When http_filter reads all of the data, it adds an eos
bucket to the end of the brigade.  ap_get_client_block continues to read
data until it gets the eos bucket.  This allows filters to increase the
size of the body data.


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

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

AP_DEBUG is defined.

ap_get_client_block():
. avoid some cases where we leak a temporary bucket brigade
. clean up/fix the logic to copy a brigade into the caller's buffer;
  the wrong length was used in some cases
. add an AP_DEBUG-only assertion for some assumptions made regarding
  the brigade returned by the filters

Submitted by:	partly by Greg Stein, but of course anything bad is mine


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

If ap_get_brigade() returns APR_SUCCESS but an empty brigade, bail out.
Previously, we kept going and sometimes segfaulted while operating on
what we thought was the first bucket.

Free the temporary brigade used by getline().


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

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

  Completes the port of the <Directory /> handling for Win32... there is
  still a patch needed for OS2 ... Brian?


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

pointers are replaced with a global table that allows modules to register
their bucket types.  Those bucket types are then allowed to be used in
the server processing.  This also required removing all direct calls to
those functions.  The ap_bucket type has an index into an array, so in
each ap_bucket_* function, we use that index to find the correct set of
functions.


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

once we finish writing the request body to the cgi child process;
otherwise, the client doesn't hit EOF on stdin.  Small request bodies
worked without this change (for reasons I don't understand), but large
ones didn't.


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

  http_filter() - this was referencing e->length even though e->length
    is sometimes -1 (if we have to read the socket bucket to get the
    next bit of the request body); now it does e->read() to force a
    socket need if required
  ap_get_client_block() - this was getting a brigade back with the
    desired amount of data (yeah, right) but only copying out the first
    bucket


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

get_brigade code should also use apr_ssize_t.
Submitted by:	Greg Stein


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

  Modify ap_make_dirstr_prefix, platforms with HAVE_DRIVE_LETTERS or NETWARE
  can request 0 elements, returning the '/' root.
  [William Rowe, Tim Costello]  from 1.3, with documentation


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

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

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

specific value, and therefore it belongs in the ap_bucket_file type,
which was also created with this commit.  ap_bucket needs to be as generic
as possible to make it easily extensible, which means we have to keep
the generic ap_bucket type very separate from ap_bucket_foo.


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

values for the length, -1, 0, and a positive number.  -1 means that the
next filter should return all the data it has, the current filter will
take care to ensure that the protocol is followed.  Most filters will
never use this, because it implies they are implementing a conn_based
input filter.  0 means give me exactly one line of data.  A positive
number means give me a maximum of n bytes.


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

  Move more path parsing fixes forward from 1.3


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

  I hope this clarifies.  Greg is absolutely correct, there is no need for
  any modules symbol other than AP_MODULE_DECLARE_DATA, since module .h
  files containing imports and exports imply something more sophisticated,
  as the early mod_dav.c example illustrated.


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

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

doesn't make much sense to check to see if there is something there.  This
removes the input_data brigade from the conn_rec altogether.  There is no
good reason for a filter to be accessing a bucket brigade from within the
conn_rec.  This shouldn't be here anymore, just like the output_filter
shouldn't be storing the data in the conn_rec.


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

with the bucket design, so they need to go away.


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

cgid module.


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

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

again.  Chunking input doesn't work with this change, but that is because
this is a stop-gap to get POSTs working again.


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

one or more rlimit controls.  (Solaris 2.8 hits both of these.)


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

anymore because getline() returns < 0 upon EOF.
There are also a few very minor tweaks to getline() -- remove an
unused variable, remove a couple of unnecessary comments, simplify
an error path.


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

works for me, but please beat it up and review.

Submitted by: Jeff Trawick, Greg Ames


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