FS provider from the public API; bang up the FS internals for the
    now-private items and mechanisms; a bit more revamp to the FS walker
    top-level APIs to narrow in on obsoleting dav_walker_ctx.


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

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

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

  (e.g. fetch /foo/ which redirects to /foo/index.html)


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

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

things the first time.  The server compiles again after this change.


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

requests.  This allows the byterange filter to work with the PDF plug-in.


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

content-length has already been set.  If we don't, then we won't know if
the content-length has changed because some other filter changed the
length of the actual data.  We also ALWAYS want to calculate the content
length if we get the whole brigade in the first call to this function.


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

a part of the server until the proxy is purged of BUFF however.


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

before serving, since a filter may have caused the file pointer
to advance.


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

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

if we decided to do so initially *and* we've seen all the data.

Prior to this change, for a http/1.1 request to mod_autoindex, the
unconditional call to ap_set_content_length() gave us the wrong
value (only taking into account the first brigade) and disabled
chunking.


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

is completely in the core now.

Note that file handle caching is broken (nothing to do with
byte ranges).  mmap caches seem to work o.k.


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

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

The sscanf() call was actually broken.


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

functions to use it.  This is onyl the start and I'll pause a while before
I continue in case people really hate this.  The patch can be backed out and
all evidence will be removed, but I think this makes maintaining/developing
the code easier in the long term.


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

This file will need a lot of work as it's using a lot of "raw" information
from socket structures that won't work with IPv6.  Needs to be abstracted out
and use APR instead.


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

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

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

of a few...


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

there is still some bogosity in there (huge buffer allocs!), and some
optimizations to be made, but this appears to fix byterange handling.


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

Acrobat plug-in doesn't like it for some reason.  This does work better
than what we currently have, because at least it returns all of the
requested data.  This basically removes all BUFFs from the byte-range
code and removes all of the byte-range code from the default-handler.

Byte-ranges are now handled by a filter, which makes sense, and it allows
us to handle byte-ranges for all requests, not just files.


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

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

can't check the return code.


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

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

the byterange handling and ap_set_content_length().

[ ap_each_byterange() remains as an apr_size_t* so we don't mess up callers ]


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

with no sendfile().


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

signed values in these integers, and we return the error codes directly,
so we should always report the number of bytes read/written correctly.  If
we have an error, that is 0 bytes.  If that is true, then using signed
values doesn't make any sense.


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

while, and this is cluttering up the code.  If it is really needed, it
can be found in CVS


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

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

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

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

client or not.  The reason for this, is that it allows us to log the
bytes sent to the client correctly.  This also simplifies the
content-length filter a bit, by making it a single pass through the
brigade.


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

because it didn't signify the end of the brigade, and it didn't signify
the end of a response.  It ended up meaning flush the data, which can be
detemined with bucket type checks.  This also makes the FLUSH and EOS
buckets have a 0 length, which makes a lot of code cleaner, because now we
can just add lengths and be sure they are all >=0.


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

Submitted by:	Chris Pepper <pepper@mail.reppep.com>


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

trace of that possibility from the code.  First of all, there is nothing
that says you can only send one file bucket in a response, and second,
even if a handler sends a file, nothing says that it can't add text before
or after it too.


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

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

Submitted by:	Chris Pepper <pepper@mail.reppep.com>


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

Submitted by:	Chris Pepper <pepper@mail.reppep.com>, Joshua Slive


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

the first request if this is a keepalive connection.  This allows us to
save the end of the first request until we have enough data from the
second request to make it worthwhile to send the responses.  In order
to do this, we need to allocate mmap's from the connection pool instead
of the request pool.  If we don't use the connection pool, then the mmap
is freed before the data is sent, because the mmap is freed at the end of
the first request.


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