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
Garbage characters sometimes appeared after a legitimate folded header.
We weren't allocating an extra byte for the trailing null, or copying it,
when called from get_mime_headers (folding is in use, and ap_rgetline is
responsible for allocating memory). No need to worry about a trailing
LF - it's already been nuked.
I checked the partial line code to see if it had a similar bug. It looked
like it did, and that the code which trims the back end of the line would
run multiple times and whack innocent bytes. However, gdb showed that this
section of code appears to be dead due to input filter chain changes.
also, removed an assignment to a dead variable.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93804 13f79535-47bb-0310-9956-ffa450edef68
normal case worked OK, but due to the recursion and multiple exit points,
input bytes could go thru charset translation multiple times or not at all.
Suggested by: Justin Erenkrantz
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93776 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
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
so make sure that it doesn't get left lying around. This tickled
a bug with mod_deflate and resulted in a bucket being compressed
more than once.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93610 13f79535-47bb-0310-9956-ffa450edef68
LogLevel 'debug' and complain if they see anything that says "error"
in it. This case isn't even interesting unless you are hard-core.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93422 13f79535-47bb-0310-9956-ffa450edef68
called.
This fixes a number of segfaults on daedalus where the first line is
empty (i.e. \r\n followed by a bunch of garbage)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93332 13f79535-47bb-0310-9956-ffa450edef68
returned something like APR_EOF, since len is not set in this
case and we can go off the end of storage
make sure we set r->status to something when we bail out due
to an error; otherwise, the request goes forward with meaningless
headers
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93294 13f79535-47bb-0310-9956-ffa450edef68
It's something to note, but it isn't an error worthy of logging by default.
(Also always log any status values in read_request_line() - incl. timeouts.)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93271 13f79535-47bb-0310-9956-ffa450edef68
segfault.
(A minor change to Jeff's patch is that we ignore the EBCDIC code path.)
Submitted by: Jeff Trawick
Reviewed by: Justin Erenkrantz
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93269 13f79535-47bb-0310-9956-ffa450edef68
use when we do AP_MODE_SPECULATIVE. This allows us to delete the
brigades earlier.
(In practice, it really doesn't matter if we delete the brigade or not
since it will be destroyed when it's pool is destroyed, but we'll try
to be nice.)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93092 13f79535-47bb-0310-9956-ffa450edef68
ap_rgetline()...
In the "folding" case, there was an ap_get_brigade() call after
the brigade had been destroyed. I noticed this while debugging
a memory leak that showed up while testing the httpd with ab.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93044 13f79535-47bb-0310-9956-ffa450edef68
generally worked but with a memory debug build it could
crash since some memory debuggers don't like an alloc of
zero bytes
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93037 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
in the core_module structure by using the AP_MODE_SPECULATIVE filter mode
to determine if MIME-continuation should occur.
Notes:
- ap_rgetline has a new prototype.
- ap_rgetline returns APR_ENOSPC when we are out of buffer space.
All direct callers of ap_rgetline are now adjusted to handle this new API.
ap_getline will mimic the old API for now.
Reviewed by: Ryan Morgan
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93011 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
Reduced the initial size of the r->headers_in and r->subprocess_env
tables...this saves us 600 bytes per request, which (based on tests
I just ran) helps keep r->pool from overflowing its initial 8KB
allocation and having to alloc another 8KB block.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92843 13f79535-47bb-0310-9956-ffa450edef68
When an input line required more than one read, each subsequent
block of data was copied on top of the previous one. So if a
request line got split into multiple packets, the data would be
corrupted. The new code uses a power-of-two allocator to expand
the buffer and properly append the next block of data at the end
of the previous one.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92558 13f79535-47bb-0310-9956-ffa450edef68
level filter that sets the timeout on the socket that is connected
to the client.
Thanks Greg Stein for seeing this bug.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92073 13f79535-47bb-0310-9956-ffa450edef68
The first step is to remove the socket from the conn_rec,
the server now lives in a context that is passed to the
core's input and output filters. This forces us to be very
careful when adding calls that use the socket directly,
because the socket isn't available in most locations.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91887 13f79535-47bb-0310-9956-ffa450edef68
change declaration from AP_CORE_DECLARE to AP_DECLARE so it can be used
used outside the core
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91778 13f79535-47bb-0310-9956-ffa450edef68
filter until after we have read the headers. This eliminates the status
hack that was in http_protocol.c and makes it all around better.
server/protocol.c now directly adds HTTP_IN filter - should we create a
specific hook for this? (Could we do this as a post_read_request hook?)
I'm not terribly sure, but let's move it down to the lowest possible
place in ap_read_request. We can change this detail later as we see fit.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91192 13f79535-47bb-0310-9956-ffa450edef68
rearranging and rethinking some things. The net result is that the HTTP
filter is now a request filter and is now only responsible for HTTP things.
The core input filter is now responsible for handling all of the dirty work.
Highlights:
- Removes the dechunk filter and merges it with ap_http_filter (aka HTTP_IN).
The dechunk filter was incorrectly handling certain cases (trailers).
- Moves ap_http_filter from a connection filter to a request filter
to support the consolidation above (it needs header info).
- Change support code to allow the http_filter to be a
request filter (how the request is setup initially).
- Move most of the logic from HTTP_IN to CORE_IN (core_input_filter).
HTTP_IN is now only concerned about HTTP things. The core filter
is now responsible for returning data. It is impossible to
consolidate dechunk and http without this because HTTP_IN previously
buffered data. As Greg has suggested, it may make sense to write
some brigade functions that handle input (getline). It should be
fairly trivial to add these. Some of the calls in ap_http_filter
could be switched as well.
This is the original patch as submitted to dev@httpd on Monday, Sep.
24th. Additional comments and some minor tweaks done after that
submission are coming up next. This should allow people who reviewed
the original patch to see what has changed and review them piecemeal.
This test passes all current tests in httpd-test. Please perform
chicken sacrifices to verify that this hasn't blown up your favorite
input.
Reviewed by: Greg Stein, Ryan Bloom, and Cliff Woolley (buckets)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91189 13f79535-47bb-0310-9956-ffa450edef68
