added on !r->main requests. This led to infinite loop/SEGV when dealing
with anything that created a subreq.
(I don't think core_create_req is a good place for adding this filter.)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93694 13f79535-47bb-0310-9956-ffa450edef68
this patch, the type wasn't too important, because all filters were
put on the same list. After this patch, the filter type is very important,
because there are three different types of filters, and they are all treated
differently, namely:
CONNECTION: Filters of this type are valid for the lifetime of this
connection.
PROTOCOL: Filters of this type are valid for the lifetime of this
request from the point of view of the client, this means
that the request is valid from the time that the request
is sent until the time that the response is received.
CONTENT: Filters of this type are valid for the time that this
content is used to satisfy a request. For simple requests,
this is identical to PROTOCOL, but internal redirects
and sub-requests can change the content without ending
the request.
It is important to realize that the three major types above are actually
broken down into smaller groups in the code, to ensure that the ordering
of filters is always correct.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93688 13f79535-47bb-0310-9956-ffa450edef68
code earlier today. With this mode, the Perchild MPM can finally be
fixed to work with filters. I have changed a comment in the core to make
it clear that this mode is required, but I have mentioned how dangerous
this mode is. Also add a comment to STATUS about my plans.
Hopefully I'll have some time this week to hack through the MPM.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93565 13f79535-47bb-0310-9956-ffa450edef68
reusing/recopying each bucket -after- inserting it into the brigade.
Also, copying bucket c from b from a seemed obtuse.
This patch creates the single bucket, makes a copy of it for each
sendfile chunk we are about to add to the brigade, and finally consumes
that initial bucket as the final file bucket of the brigade.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93534 13f79535-47bb-0310-9956-ffa450edef68
(okay, making a copy of it is cheating perhaps, but the name of the
game is to get APR_BRIGADE_NORMALIZE() out of the API)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93458 13f79535-47bb-0310-9956-ffa450edef68
specified they want to use the CanonicalName, but they have not
configured a port with the ServerName, then use the same port that
the original request used.
Submitted by: Ryan Bloom and Ken Coar
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93296 13f79535-47bb-0310-9956-ffa450edef68
since APR_BRIGADE_EMPTY() assumes a non-empty brigade, we have to check
before invoking that macro
since APR_BRIGADE_EMPTY() can make a brigade empty, we have to check
after invoking that macro
An obvious variation of this fix would be to change APR_BRIGADE_NORMALIZE()
to deal with empty brigades.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93293 13f79535-47bb-0310-9956-ffa450edef68
APR_EOF instead of an EOS bucket.
- Start to try to be nice when we *know* we are EOS by removing the
bucket. This is only one case where we could end up with a 0 bucket
in ctx->b, but let's remove it and move on. (If the bucket were to
return 0 bytes and still have data left to read on blocking mode,
it's blantly broken, IMHO)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93270 13f79535-47bb-0310-9956-ffa450edef68
APR_BRIGADE_NORMALIZE(). Otherwise, we can get segfaults if a
client says it will post some data but we get FIN before any
data arrives.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93262 13f79535-47bb-0310-9956-ffa450edef68
acheived with the pre_connection hook. I have added the socket to the
pre_connection phase to make this possible.
Reviewed by: Bill Stoddard
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93259 13f79535-47bb-0310-9956-ffa450edef68
client_socket from the conn_rec. Diffs from Ryan's patch include:
- rename the create_connection hook to install_transport_filters
- move the point of invocation of the hook till after the call to
after ap_update_vhost_given_ip to enable the hook to use vhost
config info in its decision making.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93087 13f79535-47bb-0310-9956-ffa450edef68
best you get gibberish. Much worse things can happen depending
on the OS.
This can happen when autoindex isn't loaded.
On AIX, I had a directory file which was reported to be 1536 bytes
in size. mmap() failed so we went to the fall-back logic.
The first read() got 624 bytes and the next read() got 0
(supposedly EOF). This confused us greatly, we kept allocating
buffers and reading and exercised the paging space.
Reviewed by: Bill Rowe
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93071 13f79535-47bb-0310-9956-ffa450edef68
conn_rec. The create_connection_hook has a design flaw that prevents it
from making decisions based on vhost information.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93050 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
* Change SUBREQ_CORE so that it is a HTTP_HEADER (20) filter instead of a content filter (10)
this allows subrequests to add content filters properly
* Change subreq handling of 'handle-include' so that it splits/passes the brigade before the subreq
is created. (This allows quick_handler to push content back from this phase)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92956 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
to avoid segfaults.
Using prefork MPM and APR_POOL_DEBUG and ElectricFence, I found a
couple of paths where weren't able to report APR_EOF all the way
back up the call tree, leading us back into core_input_filter with
an empty brigade.
Some of the paths in core_input_filter handled it, some didn't.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92835 13f79535-47bb-0310-9956-ffa450edef68
Basically pconf is cleared at different times from plog, and this
has the effect of leaving stderr closed when going into the next
stage of the config. This also had the effect of allowing FreeBSD
with threads to create a pipe with stderr's fd at one end, and this
resulted in problems with the signal polling and high cpu usage.
In addition, move the clearing of plog from main.c to core.c where
it seems more appropriate.
This solves the first and main problem that FreeBSD has with the
threaded MPM's.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92769 13f79535-47bb-0310-9956-ffa450edef68
ap_*_client_block to ap_http_filter (aka HTTP_IN). This is the
only appropriate place for limit checking to occur (otherwise,
chunked input is not correctly limited).
Also changed the type of limit_req_body to apr_off_t to match the
other types inside of HTTP_IN. Also made the strtol call for
limit_req_body a bit more robust.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92700 13f79535-47bb-0310-9956-ffa450edef68
Moved the directory/location/file-walk caches from the
request's pool userdata hash table to the core_request_config
struct.
This change removes about 60% of the processing time from
prep_walk_cache().
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92684 13f79535-47bb-0310-9956-ffa450edef68
I'll leave docs up to him. The conf becomes a quadstate (undef != default)
but other than that, it should make things cleaner for the user.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92459 13f79535-47bb-0310-9956-ffa450edef68
This patch allows us to force path_info off in mod_cgi[d] etc, patch
forthcoming. It also allows includes, php, etc to change the undefined
value in the early handler or late fixup phases to Accept'ed.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92448 13f79535-47bb-0310-9956-ffa450edef68
path_info served from the core handler. Any filters can then manipulate
all the usual CGI envvars [as proven with this little excerpt with a
<!--#printenv --> document...
<FilesMatch ".*\.shtml.*">
Options +Includes
SetOutputFilter INCLUDES
AcceptPathInfo on
</FilesMatch>
a potentially questionable config, but effective.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92444 13f79535-47bb-0310-9956-ffa450edef68
get a long stream of small buckets, so that multiple concatenation
steps are required in a single pass through the brigade, re-use the
buckets from the previous temp brigade when creating the next one.
This allows us to avoid making yet another copy of the previously
concatenated data.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92197 13f79535-47bb-0310-9956-ffa450edef68
don't try to concatenate buffers if we already have at least
8KB of data ready to send. Instead, just split the brigade
and send what's currently in the iovec.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92196 13f79535-47bb-0310-9956-ffa450edef68
small buckets: It's possible for the temporary brigade to
contain more than one bucket. If this happens, we need to
recover the buckets after the first from the temporary brigade
before destroying it.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92176 13f79535-47bb-0310-9956-ffa450edef68
