nothing to do with FLUSH buckets. It is simply a cover function
for ap_pass_brigade for use with the apr_brigade_* writing
functions.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@100646 13f79535-47bb-0310-9956-ffa450edef68
arbitrary code before the handlers are invoked.
This resolves an issue with incorrect 304s on If-Modified-Since mod_include
requests since ap_meets_conditions() is not aware that this is a dynamic
request and it is not possible to satisfy 304 for these requests (unless
xbithack full is on, of course). When mod_include runs as a filter, it is
too late to set any flag since the handler is responsible for calling
ap_meets_conditions(), which it should do before generating any data.
If a module doesn't need to run such arbitrary code, it can just pass NULL
as the argument and all is well.
PR: 9673
Reviewed by: Ryan Bloom and others
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95906 13f79535-47bb-0310-9956-ffa450edef68
expectations of their usage.
The reason that we should make this change now is that we have changed
the implied meaning of AP_FTYPE_HTTP_HEADER - some users of this should
be PROTOCOL while others should be CONTENT_SET. In order to clarify it,
toss all of the bogus names and force the filter writers to make sure
they understand what they are doing.
CONTENT_SET is new (horrible name - change if you have better idea), but
it indicates that it should run between RESOURCE and PROTOCOL.
mod_deflate is the ideal CONTENT_SET filter.
The changed type names are:
CONTENT is now RESOURCE.
HTTP_HEADER is now PROTOCOL. However, most filters that used HTTP_HEADER
may want CONTENT_SET. (Only things like POP and HTTP belong as PROTOCOL.)
MMN bump since all filters need to be recompiled due to filter reordering.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93756 13f79535-47bb-0310-9956-ffa450edef68
the complexity of trying to set the filter chain correctly, with the
side-effect of forcing us to walk the entire chain whenever we add
a filter. Since the filter chains are small, the decrease in
complexity is worth it.
Reviewed by: Allan Edwards
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93745 13f79535-47bb-0310-9956-ffa450edef68
solution ensures that we don't lose filters if they are added later than
we expect. The problem could be seen if a connection filter was added
after a request-based filter was added in the past. The problem was that
the request-based filters pointed to the first filter in the connection
record, so the new connection filter was never called. Now, all filters
are put on their correct filter lists, and we are sure to always update
all pointers when adding a filter.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93683 13f79535-47bb-0310-9956-ffa450edef68
ap_add_output_filter_handle()
There are many places in the core modules where we do
ap_add_input_filter() or ap_add_output_filter() on a
hardcoded filter name (e.g., "CORE" or "BYTERANGE").
This requires a string-to-filter mapping that wastes
CPU time. (Even though the string lookup uses a trie
for speed, it still ranks as a big consumer of CPU time
because of the large number of filters added per request.)
The new ap_add_*_filter_handle() functions will allow
us to skip the string-to-filter mapping in cases where
the module adding the filter happens to have the
ap_filter_rec_t* for the registered filter (e.g., because
it's the same module that registered the filter in the
first place).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93039 13f79535-47bb-0310-9956-ffa450edef68
If you need the length, you should be using apr_brigade_length. This is
much more consistent. Of all the places that call ap_get_brigade, only
one (ap_http_filter) needs the length. This makes it now possible to
pass constants down without assigning them to a temporary variable first.
Also:
- Change proxy_ftp to use EXHAUSTIVE mode (didn't catch its -1 before)
- Fix buglet in mod_ssl that would cause it to return too much data in
some circumstances
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93014 13f79535-47bb-0310-9956-ffa450edef68
separate from the input filter mode type.
We also no longer look at readbytes to determine the method of
filter operation. This makes the use of filters more obvious and
allows a wider range of options for input filters modes.
To start with, the new input filter modes are:
AP_MODE_READBYTES (no more than *readbytes returned)
AP_MODE_GETLINE (old *readbytes == 0 case)
AP_MODE_EATCRLF (old AP_MODE_PEEK)
AP_MODE_SPECULATIVE (will be used in a future ap_getline rewrite)
AP_MODE_EXHAUSTIVE (old *readbytes == -1 case)
AP_MODE_INIT (special case for NNTP over SSL)
The block parameter is an apr_read_type_e: APR_BLOCK_READ, APR_NONBLOCK_READ
This also allows cleanup of mod_ssl's handling in the getline case.
Reviewed by: Ryan Bloom (concept), Greg Stein (concept)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92928 13f79535-47bb-0310-9956-ffa450edef68
allows filters such as mod_ssl to initialize a client connection
(ie handshake) before reading request data from the client.
PR:
Obtained from:
Submitted by: dougm
Reviewed by: wrowe
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92042 13f79535-47bb-0310-9956-ffa450edef68
a pointer to the OLD_WRITE frec, and instead of using strcmp or strcasecmp,
we can just do a simple pointer comparison. This optimization is also
available to other modules.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91006 13f79535-47bb-0310-9956-ffa450edef68
over an HTTPS connection. This also adds an ap_remove_input_filter
function, which should be used to remove the SSL input filter in this
case, as soon as this code is stressed a bit more.
For right now, we are sending the same message that we used to send in
mod_ssl for Apache 1.3.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90724 13f79535-47bb-0310-9956-ffa450edef68
ap_input_mode_t. It's now safe(r) to cast from ap_read_type_e to
ap_input_mode_t.
Submitted by: Justin Erenkrantz, Sander Striker
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89671 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
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
