must be semicolon delimited (if more than one filter is given.)
The Set{Input|Output}Filter directive now overrides a parent
container's directive (e.g. SetInputFilter in <Directory /web/foo>
will override any SetInputFilter directive in <Directory /web>.)
This new syntax is more consistent with Add{Input|Output}Filter
directives defined in mod_mime. Also cures a bug in prior releases
where the Set{Input|Output}Filter directive would corrupt the
global configuration if the multiple directives were nested.
[William Rowe]
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90799 13f79535-47bb-0310-9956-ffa450edef68
introduce the ForceType and SetHandler [absolute references] directly
into the very top of the fixups phase. This means these will always
override _any_ mime module, not just mod_mime. Ergo, other mime modules
can continue to set charset, encodings, etc. Since these are globals,
they belong in the core.
This highlights a very serious drawback to the type_checker hook. By
using run first, a module that identifies _partial_ information (maybe
just the content type) won't pass the query on to other modules, like
mod_mime, that might further define the encoding or charset. The
type_checker hook should clearly become a run-all, and the modules should
decline if they see someone ahead of them answered a question they were
going to try to figure.
Which means - if type_checker becomes RUN_ALL - this new override hook
fn should become a type_checker again - and RUN_REALLY_FIRST, and let
other modules _choose_ not to override this election. (We can run it
again at the end, for a recount ;) Votes?
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90797 13f79535-47bb-0310-9956-ffa450edef68
(and now AddInputFilter and AddOutputFilter by extension) so this seems
entirely appropriate in the core as well. Options FileInfo is required
to change the processing behavior of files.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90760 13f79535-47bb-0310-9956-ffa450edef68
keepalive requests. We were allocating a brigade out of the
connection pool; the number of these brigades allocated
per connection was theoretically unlimited.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90736 13f79535-47bb-0310-9956-ffa450edef68
ap_directory_walk() phase. Modules that want to use special
walk logic should refer to the mod_proxy map_to_location example,
with it's proxy_walk and proxysection implementation. This makes
either directory_walk flavor much more legible, since that phase
only runs against real <Directory > blocks.
On a technical note, this patch also forces the Directory to be
canonical (unless it is "/" or a regex.) It also allows us to
be more explicit when declaring <Directory > block errors.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90684 13f79535-47bb-0310-9956-ffa450edef68
the directory_walk and file_walk for non-file requests. TRACE
shortcut moved to http_protocol.c as APR_HOOK_MIDDLE, and the
directory_walk/file_walk happen as APR_HOOK_VERY_LAST in core.c.
A seperate patch to mod_proxy is required to short circuit both the
TRACE and directory_walk/file_walk stuff. That patch is next.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90665 13f79535-47bb-0310-9956-ffa450edef68
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
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
URI does not go above the DocumentRoot (as defined by the OS, not by
the URI specification), and give us the true name.
When we are done, note the name is canonical for directory_walk.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90593 13f79535-47bb-0310-9956-ffa450edef68
Therefore we will canonicalize it when it doesn't match filename.
The next optimization should take the path common to canonical_filename
and filename, and start merging filename from there for canonicalization.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90591 13f79535-47bb-0310-9956-ffa450edef68
MPMs use the same functions for all common MPM directives. This
should make it easier to catch all bugs in these directives once.
Everybody should check their favorite MPM to ensure that it still
compiles, and that these directives work. This is a big patch, and
although it looks good, and things compiled for me, that is no
garauntee that it will work on all platforms. :-)
Submitted by: Cody Sherr <csherr@covalent.net>
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90132 13f79535-47bb-0310-9956-ffa450edef68
and have those methods <limit>able in the httpd.conf. It uses
the same bit mask/shifted offset as the original HTTP methods
such as M_GET or M_POST, but expands the total bits from an int to
an ap_int64_t to handle more bits for new request methods than
an int provides.
Submitted by: Cody Sherr <csherr@covalent.net>
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89869 13f79535-47bb-0310-9956-ffa450edef68
for this solution. I'm easily convinced to choose AP_MAX_SENDFILE based
on any reasonable argument, provided it's smaller than 2^30 :-)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89714 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
This patch was submitted by Ian Holsman. Greg revised some names, applied
the Apache style, and namespace-prefixed the public symbols. Minor bugfix in
the use of the hook implementation macro.
Submitted by: Ian Holsman <IanH@cnet.com>
Reviewed by: Greg Stein
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89364 13f79535-47bb-0310-9956-ffa450edef68
default_handler was using the subrequest pool for files and
MMAPs, even though the associated APR structures typically
live longer than the subrequest.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89354 13f79535-47bb-0310-9956-ffa450edef68
again. The problem is that the amount of data read from the network,
is not necessarily the amount of data returned from the filters. It is
possible for input filters to add bytes to the data read from the network.
To fix the original bug, I just removed the line from ap_get_client_block
that decremented r->remaining, we allow the http_filter to do that for
us.
I have also removed an incorrect comment.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89041 13f79535-47bb-0310-9956-ffa450edef68
which corresponded to r->remaining (in ap_get_client_block). However,
ap_get_client_block was *also* adjusting r->remaining. Net result was that
PUT (and probably POST) was broken. (at least on large inputs)
To fix it, I simply removed the indirection on "readbytes" for input
filters. There is no reason for them to return data (the brigade length is
the return length). This also simplifies a number of calls where people
needed to do &zero just to pass zero.
I also added a number of comments about operations and where things could be
improved, or are (semi) broken.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89008 13f79535-47bb-0310-9956-ffa450edef68
we have to use nbytes+flen when figuring out how much data we have,
and when looking at the fact that we have a buffer to save aside before
sending it, we also need to look at the length, to ensure that we aren't
saving too much.
Submitted by: Bill Stoddard and Ryan Bloom
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88972 13f79535-47bb-0310-9956-ffa450edef68
Delay the check for "too many items in an iovec" until we actually try to
put something in there. This allows that N+1 bucket to be an EOS, FLUSH,
FILE, or zero-length bucket without triggering a split. Only if that next
bucket has iovec data will a split be made.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88969 13f79535-47bb-0310-9956-ffa450edef68
connection pool. This solves a small resource leak that had us
not closing files until a connection was closed. In order to do
this, at the end of the core_output_filter, we loop through the
brigade and convert any data we have into a single HEAP bucket
that we know will survive clearing the request_rec.
Submitted by: Ryan Bloom, Justin Erenkrantz <jerenkrantz@ebuilt.com>,
Cliff Woolley
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88964 13f79535-47bb-0310-9956-ffa450edef68
determine how much data is returned to the previous filter. Prior to this
change, we used a field in the conn_rec to determine how much to return.
After this change, we use an argument to ap_get_brigade. This makes it
much more obvious how things work at all levels, so that module authors
can easily determine how much data is supposed to be returned to them.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88912 13f79535-47bb-0310-9956-ffa450edef68
told me I was wrong. I was wrong, and Greg was right. This commit
just moves the byterange filter and its related functions out of the core,
and puts them back in the HTTP specific module.
Submitted by: Greg Stein
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88815 13f79535-47bb-0310-9956-ffa450edef68
