init functions for connection filters (doing an "init" once per
handler invocation makes no sense for a connection filter). No longer
run init functions multiple times per request if a subrequest is used.
* include/util_filter.h (ap_filter_rec_t): Clarify use of the init
function pointer.
* server/config.c (invoke_filter_init): Drop ap_ prefix for private
function; take a request_rec pointer and only invoke filters with
matching request.
(ap_invoke_handler): Adjust accordingly.
PR: 49328
Reviewed by: rpluem
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@953311 13f79535-47bb-0310-9956-ffa450edef68
I added a few more fixes, and there are still more that might
need a doxygen expert.
PR: 48061
Submitted by: Brad Hards
Reviewed by: poirier
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@830527 13f79535-47bb-0310-9956-ffa450edef68
current practice and the advice from manual/developer/output-filters.xml.
Submitted by: Rici Lake <rici ricilake.net>
Reviewed by: Stefan Fritsch, Joe Orton
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@822870 13f79535-47bb-0310-9956-ffa450edef68
the status code returned by a handler by updating the values of the filter
error macros and consolidating them in httpd.h
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@721677 13f79535-47bb-0310-9956-ffa450edef68
request_rec pointer when adding connection filters; minor MMN bump:
* server/util_filter.c (add_any_filter_handle): Set f->r for
connection filters even if passed-in r is non-NULL. Style nit fix
also.
* include/util_filter.h (ap_add_output_filter,
ap_add_output_filter_handle): Document new API guarantee.
* include/ap_mmn.h: Minor MMN bump.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@600473 13f79535-47bb-0310-9956-ffa450edef68
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
