buckets also in the request structure of the redirect issuer(s). This
prevents filters (such as mod_deflate) to add garbage to the response,
because ap_finalize_request_protocol won't send another EOS bucket then.
PR: 14451
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@98699 13f79535-47bb-0310-9956-ffa450edef68
This clears the list of renames pending in apr-util.
Parts of this list was alreadu done, but the pending list hadn't been updated.
apr_hook_debug_current from apr_current_hooking_module
apr_hook_debug_show from apr_show_hook
apr_hook_global_pool from apr_global_hook_pool
apr_hook_sort_all from apr_sort_hooks
apr_uri_port_of_scheme from apr_uri_default_port_for_scheme
apr_uri_unparse from apr_uri_unparse_components
apr_uri_parse from apr_uri_parse_components
apr_uri_parse_hostinfo from apr_uri_parse_hostinfo_components
apr_uri_t from apr_uri_components
All APR_URI_* from all APU_URI_* symbols
All APR_UNP_* from all UNP_* symbols
PR:
Obtained from:
Submitted by: Thom May
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95966 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
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
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
must set the r->output_filter to r->proto_output_filter. If we don't,
then as soon as we insert the request filter, the protocol filter will
be removed. This was causing headers to not be sent on some requests.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93692 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
were not getting the correct filters. This is done by creating a location
in the request rec that holds protocol level filters. Protocol level
filters survive for one request, from the time the request is received
from the user to the time the response is sent. r->output_filters now
stores the request level filters, which are only valid for the lifetime
of one request_rec.
This patch works, but it is not complete. The second half of the problem
is that add_any_filter doesn't check where it puts the filters that it
adds, so it is possible for filters to be put on this wrong list, and
for filters to be lost completely during request processing. That half
of the fix will be coming in the next day or so.
Submitted by: Will Rowe, Justin Erenkrantz, Ryan Bloom
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93682 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
I decided it's more plesant to let the cpu not to think so hard (no
wasted space, the c member will by word aligned anyways.)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92449 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
through the list of registered filters. This patch replaces the linear
list with a hash table for better performance.
Submitted by: Brian Pane <bpane@pacbell.net>
Reviewed by: Justin Erenkrantz
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90888 13f79535-47bb-0310-9956-ffa450edef68
it possible to wipe out the entire filter chain. and then when
ap_finalize_request_protocol was called, r->output_filters was NULL,
preventing data from being flushed to the client.
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90801 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
setaside function. It simply returns APR_SUCCESS.
- adjust the EOS, FLUSH, IMMORTAL, and HEAP buckets to use _noop.
*) Make the setaside() function take a pool to define the (new) lifetime for
the bucket's data.
- Adjust the apr_bucket_setaside() macro.
- Adjust the apr_bucket_setaside_notimpl() and transient_setaside()
functions.
- Pass the additional parameter in ap_save_brigade()
*) Update docs for setaside()
*) Minor nit with macros in apr_buckets.h: add parens for binding safety.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89289 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
not to the filter after the one passed in. The fixes a bug, where one
filter is skipped when using ap_f*.
Submitted by: Ryan Morgan <rmorgan@covalent.net>
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88832 13f79535-47bb-0310-9956-ffa450edef68
