Per new-httpd discussions, this version of mod_autoindex has been set
  aside as a test for rputs style backwards compatibility.  It has really
  horrid chunking charateristics, so it was the ideal nominee for the job.

  Please refer to src/modules/standard/mod_autoindex.c for the complete
  revision history.  When rputs is entirely eliminated (if it ever is)
  then this version should be eliminated.


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

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

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

Alter http_vhost.c to use the new apr_get_inaddr fucntion.  Old code is still
there just in case it breaks.  can someone check it who knows this stuff?


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

  Return buff.h to the winnt mpm till Bill (or I, if I must) remove the
  acceptex style contexts into apr.


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

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

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

    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