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
causing the server not to start.
previous method was to call exit(1) which would not fail
gracefully
PR:
Obtained from:
Submitted by:
Reviewed by: (Idea only Jeff Trawick)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92144 13f79535-47bb-0310-9956-ffa450edef68
sent, the core will send the first 16 buckets, regardless of how much
data there is. In the pathological case, this can cause a lot of 16
byte packets. Now, if we see less than AP_MIN_BYTES, we combine
all of the buckets into a single bucket to be sent in a later packet.
This can cause a lot of memory copies, but it eases our network traffic.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92097 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
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
many bugs. Instead, it is called where it used to be called. I have
abstracted some of the logic out of the lingering close so that it gets
the socket from the connection using the core's conn_config vector. This
is in anticipation of a change to use a hook for the lingering close,
which I hope to do soon.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91968 13f79535-47bb-0310-9956-ffa450edef68
current compiler errors. Basically, the core now puts the socket
in the conn_rec->conn_config vector. The proxy grabs that socket and
uses it where it used to use the client_socket field from the conn_rec.
Long-term, all of the direct socket communication needs to be removed,
and this should go through a filter stack. Short-term, this gets the
proxy working again.
I have tested http and connect, but I haven't looked at the FTP proxy,
although it does compile now.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91952 13f79535-47bb-0310-9956-ffa450edef68
make sure that we have a socket that the core controls if we do this,
but it is more correct.
Submitted by: Greg Stein
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91922 13f79535-47bb-0310-9956-ffa450edef68
takes the old ap_new_connection, and puts into the new core_create_conn
function. There is no good reason to have two functions to do this.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91890 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
referential uri's, and updated the manual accordingly.
XXX There is a kludge here: XXX the port number from the client's Host:
header used to be tossed, and there is no clean mechanism to pass it
(in the request_rec) to other consumers. As the unparsed_uri structure
(which could avoid repeated parsing of URI, Host, Port etc) seems to be
mostly unused currently, I used that to pass the port.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91798 13f79535-47bb-0310-9956-ffa450edef68
server_rec->port is now set to zero, not 80. That allows for
run-time deduction of the correct server port (depending on
SSL/plain, and depending also on the current setting of
UseCanonicalName). This change makes redirections
work, even with https:// connections. [Martin Kraemer]
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91797 13f79535-47bb-0310-9956-ffa450edef68
