because of the changes to the argument lists of apr_mmap_dup and apr_socket_create,
2.1-dev won't build with apr and apr-util's 0.9 branch anymore
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@101154 13f79535-47bb-0310-9956-ffa450edef68
on startup.
mod_file_cache keeps a hash table in the cmd->pool and puts an entry in
that hash table for each of its files and mmaps, all of which are opened
into cmd->pool. But it registered a cleanup on cmd->pool that would walk
the hash table and close each file and delete each mmap, even though by
the time that happened those things would have been done already anyway
by the files' and mmaps' own cleanups on cmd->pool. So it was deleting
mmaps that were already cleaned up and closing files that were already
cleaned up in all cases. This has never been valid... amazed it ever
worked. But apparently the true bogosity wasn't revealed until the new
mmap cleanup code went into APR.
PR: 16313
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@98463 13f79535-47bb-0310-9956-ffa450edef68
that it would actually get called. This fixes a core dump
at init everytime you use the MMapFile directive. [Paul J. Reder]
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94721 13f79535-47bb-0310-9956-ffa450edef68
Add an allocator-passing mechanism throughout the bucket brigades API.
From Apache's standpoint, the apr_bucket_alloc_t* used throughout a given
connection is stored in the conn_rec by the create_connection hook. That
means it's the MPM's job to optimize recycling of apr_bucket_alloc_t's --
the MPM must ensure that no two threads can ever use the same one at the
same time, for instance.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94304 13f79535-47bb-0310-9956-ffa450edef68
of Jeff Trawick's style changes to the first patches. Doesn't include
the fixes to ssl [more complex], and we won't trap errors that involve
ap_serverroot, since we presume that was normalized on the way in.
Therefore, testing ap_server_root_relative(DEFAULT_FOO) cases
should never become necessary.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93965 13f79535-47bb-0310-9956-ffa450edef68
causing the server not to start.
previous method was to call exit(1) which would not fail
gracefully
PR:
Obtained from:
Submitted by:
Reviewed by: (Idea only Jeff Trawick)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92144 13f79535-47bb-0310-9956-ffa450edef68
be treated as a 32-bit integer, and it will wrap after being shifted
32 times.
Submitted by: Cody Sherr <csherr@covalent.net> and
Ryan Morgan <rmorgan@covalent.net>
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90090 13f79535-47bb-0310-9956-ffa450edef68
and apr_bucket_file_make().
*) Simplify mod_file_cache's sendfile_handler by taking advantage
the new ability of file buckets to handle files opened in XTHREAD
mode. [Also inlined some of the brigade construction stuff in
mod_file_cache's handlers to save a palloc() or two.]
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89438 13f79535-47bb-0310-9956-ffa450edef68
filter chain. This is not perfect but better. Need to do some
more work in apr_os_file_put to initialize fields a bit better.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89086 13f79535-47bb-0310-9956-ffa450edef68
content-length and last-modified headers for performance.
Submitted by: Mike Abbot <mja@trudge.engr.sgi.com>
Reviewed by: Bill Stoddard
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88292 13f79535-47bb-0310-9956-ffa450edef68
apr_stat/lstat/getfileinfo. These are -NOT- optimal, they
are simply the required changes to get the server working.
The size of the patch is a warning about how we need to
really look at what we are trying to accomplish with all
of these stat/lstat calls.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87760 13f79535-47bb-0310-9956-ffa450edef68
is to make certain that only apr_sendfile() will be used to send content with a cached file handle.
This assumes that apr_sendfile() should not rely on the position of the file pointer. I suspect that
sendfile implementations that rely on the position of the file pointer are broken and we should not
use sendfile on those platforms.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87654 13f79535-47bb-0310-9956-ffa450edef68
