they are currently storing. There is no way we can force them to flush,
but we can advise. This also adds the code to ap_rflush to use flush
buckets, although it isn't enabled yet. I will enable it once we remove
buff from the code. I also removed all calls to ap_rflush that are either
immediately before or immediately after a call to ap_finalize_protocol.
ap_finalize_protocol sends an EOS bucket, which also advises filters to
flush their data, so having both calls right next to each other is
redundant.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86619 13f79535-47bb-0310-9956-ffa450edef68
brigade generated by the sub-request. If this is not done, then the
main-request's core_output_filter will get very confused, as will any other
filter in the main-request filter-stack that looks for EOS.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86618 13f79535-47bb-0310-9956-ffa450edef68
Get rid of an assertion which assumed that HTTP_IN is the filter
below us. Some other filter may play the same role.
ap_setup_client_block():
Get rid of a commented-out hack which was used to allow chunked
transport encoding of a request body received by mod_cgi[d].
ap_get_client_block():
Get rid of special handling for zero-length buckets... The main
loop handles that fine.
Submitted by: Ryan Bloom
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86614 13f79535-47bb-0310-9956-ffa450edef68
get dechunking working
verify that infrastructure for input filters works
(use existing AddInputFilter directive)
Unlike with my previous patch, ap_get_client_block() saves state between
calls in the core's per-request dir config.
Unlike with my previous patch, HTTP_IN keeps a count of remaining bytes
in the conn_rec. Code that needs to prod it to deliver a certain amount
of request body plays with conn_rec->remain directly.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86613 13f79535-47bb-0310-9956-ffa450edef68
for CORE_EXPORT to AP_CORE_DECLARE (namespace protecting the wrapper)
and retitled API_EXPORT as AP_DECLARE and APR_EXPORT as APR_DECLARE.
All _VAR_ flavors changes to _DATA to be absolutely clear.
Thank you Greg, for the most obvious suggestion.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86609 13f79535-47bb-0310-9956-ffa450edef68
a pointer to a static structure. The ap_foo_type functions have also been
replaced with simple macro calls. I am going to replace the
ap_bucket_(read|split|setaside|destroy) functions with macros soon.
Reviewed by: Will Rowe
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86597 13f79535-47bb-0310-9956-ffa450edef68
doesn't actually do anything useful, it was meant to remove all zero
length buckets before trying to read from the brigade. However, it is
perfectly fine to not do this, and to just read those buckets along with
the rest of them.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86589 13f79535-47bb-0310-9956-ffa450edef68
missing some major pieces that I only found after the commit. This patch
fixes the problem, and makes sure that request bodies are always ended
with an EOS bucket.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86588 13f79535-47bb-0310-9956-ffa450edef68
basic design has ap_setup_client_block setting a field in the conn_rec
which tells http_filter how much data is in the body (with chunking this
will represent how much data is in the chunk). The ap_get_client_block
then calls down the stack with the maximum amount of data that it can
receive back. When http_filter reads all of the data, it adds an eos
bucket to the end of the brigade. ap_get_client_block continues to read
data until it gets the eos bucket. This allows filters to increase the
size of the body data.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86586 13f79535-47bb-0310-9956-ffa450edef68
AP_DEBUG is defined.
ap_get_client_block():
. avoid some cases where we leak a temporary bucket brigade
. clean up/fix the logic to copy a brigade into the caller's buffer;
the wrong length was used in some cases
. add an AP_DEBUG-only assertion for some assumptions made regarding
the brigade returned by the filters
Submitted by: partly by Greg Stein, but of course anything bad is mine
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86583 13f79535-47bb-0310-9956-ffa450edef68
If ap_get_brigade() returns APR_SUCCESS but an empty brigade, bail out.
Previously, we kept going and sometimes segfaulted while operating on
what we thought was the first bucket.
Free the temporary brigade used by getline().
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86581 13f79535-47bb-0310-9956-ffa450edef68
pointers are replaced with a global table that allows modules to register
their bucket types. Those bucket types are then allowed to be used in
the server processing. This also required removing all direct calls to
those functions. The ap_bucket type has an index into an array, so in
each ap_bucket_* function, we use that index to find the correct set of
functions.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86575 13f79535-47bb-0310-9956-ffa450edef68
http_filter() - this was referencing e->length even though e->length
is sometimes -1 (if we have to read the socket bucket to get the
next bit of the request body); now it does e->read() to force a
socket need if required
ap_get_client_block() - this was getting a brigade back with the
desired amount of data (yeah, right) but only copying out the first
bucket
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86573 13f79535-47bb-0310-9956-ffa450edef68
values for the length, -1, 0, and a positive number. -1 means that the
next filter should return all the data it has, the current filter will
take care to ensure that the protocol is followed. Most filters will
never use this, because it implies they are implementing a conn_based
input filter. 0 means give me exactly one line of data. A positive
number means give me a maximum of n bytes.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86567 13f79535-47bb-0310-9956-ffa450edef68
doesn't make much sense to check to see if there is something there. This
removes the input_data brigade from the conn_rec altogether. There is no
good reason for a filter to be accessing a bucket brigade from within the
conn_rec. This shouldn't be here anymore, just like the output_filter
shouldn't be storing the data in the conn_rec.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86560 13f79535-47bb-0310-9956-ffa450edef68
again. Chunking input doesn't work with this change, but that is because
this is a stop-gap to get POSTs working again.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86555 13f79535-47bb-0310-9956-ffa450edef68
anymore because getline() returns < 0 upon EOF.
There are also a few very minor tweaks to getline() -- remove an
unused variable, remove a couple of unnecessary comments, simplify
an error path.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86553 13f79535-47bb-0310-9956-ffa450edef68
to follow. This code works for browser based requests and line-based
telnet requests. It is untested with character-based telnet requests.
I will be testing that very soon.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86549 13f79535-47bb-0310-9956-ffa450edef68
currently, but it is a step in the right direction. Input filtering
should be slowly improving from here on out.
Submitted by: Greg Ames, Ryan Bloom, Jeff Trawick
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86547 13f79535-47bb-0310-9956-ffa450edef68
instead of bucket->destroy(). bucket->destroy() wasn't being
called correctly and also we were leaking the storage for the
bucket itself since bucket->destroy() doesn't free the ap_bucket.
Submitted by: Ryan Bloom, Jeff Trawick
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86544 13f79535-47bb-0310-9956-ffa450edef68
this is not the change to allow us to read broken-up header lines again :(
. http_filter()
- respect apr_status_t as set by bucket->read() or ap_get_brigade()
- return apr_status_t instead of length
. ap_get_client_block()
- remove a confusing line which set the length parameter before
- passing it to bucket->read()
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86517 13f79535-47bb-0310-9956-ffa450edef68
sense anymore, because the BUFFs that Apache used to use it for have all
been replaced with buckets. BUFFs can't be used with filters, and Apache
doesn't use these functions anywhere anymore, so they need to go away now.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86439 13f79535-47bb-0310-9956-ffa450edef68
is a step in the right direction. The idea is that the http_filter knows
about the http protocol. So, it uses that knowledge to discover HTTP
request headers, and sends those headers up to getline. However, it keeps
the request body saved in it's ctx pointer.
Later, when ap_get_client_block is called, we have set the remaining field
in the conn_rec. This tells the http_filter how much of the remaining
data is request body, and how much isn't. So, the http_filter can return
the request body unparsed up throught ap_get_client_block.
This doesn't even try to work with chunked input data, and there are still
some other bugs in it, but it works for small-ish files in my tests, and
it lets other people play with the concept of input filters. I will try
to play with this more, but others should feel free to hack around in it
too.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86426 13f79535-47bb-0310-9956-ffa450edef68
is that the bucket code does not respect the length passed into it. This
is correct for buckets, but it means that when we get data out of the
buckets, we may have to split the bucket to make sure that any copy
operations are safe. We were originally doing the split at the number of
characters read from the bucket, but we really want to do it at the length
of the buffer.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86415 13f79535-47bb-0310-9956-ffa450edef68
replacing the majority of fallible rv == APR_condition tests. But there
are lots more to fix, these are the obvious ones that already did proper
canonical error conversion.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86405 13f79535-47bb-0310-9956-ffa450edef68
1) separate filter lists hanging off the r and the c
requests start off with the same filter list as the connection
the input filter list is not initialized for subrequests
internal redirects start off with the same filter list as the
connection
2) AddInputFilter directive (blatant rip-off of Ryan's AddOutputFilter
directive); as with AddOutputFilter, the network is implicitly to the
right of the specified filter list; this may not be the most
intuitive way to specify the filters; not sure yet
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86403 13f79535-47bb-0310-9956-ffa450edef68
charset of response bodies.
ap_checkconv() is removed, except for in os/bs2000 and os/tpf.
(Anything there is questionable for 2.0 anyway.)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86400 13f79535-47bb-0310-9956-ffa450edef68
lines (netcat) gets a strange looking HTTP_NOT_IMPLEMENTED message.
While I'm in there, start working on ebcdic co-existance with input
filtering.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86397 13f79535-47bb-0310-9956-ffa450edef68
request_rec. This means that a conn_rec must be supplied when calling
ap_add_filter. The reason for this change is that we need to be able to
add the core_filter (whether or SSL or not) before we try to read the
request. This way, if a request fails, we can actually send the error
page back to the client. With this change, we add the core filter to the
conn_rec during the pre-connection phase.
Submitted by: Ryan Bloom, Jeff Trawick, and Greg Ames
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86392 13f79535-47bb-0310-9956-ffa450edef68
instead of the number of bytes sent.
default_handler() ignores the ap_send_fd() return code, but
mod_file_cache doesn't. When mod_file_cache's handler called
ap_send_fd(), the client would get the desired file plus an
error document (500 internal server error), which was delivered
because mod_file_cache's handler returned an error since
ap_send_fd() returned non-zero.
Also in this commit is a hack to be able to compile when APACHE_XLATE
is defined.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86380 13f79535-47bb-0310-9956-ffa450edef68
This implementation is limited to coalescing a single string of small (< MIN_BUCKET_SIZE)
buckets into one large bucket. If a brigade contains a string of small buckets followed by a
large bucket followed by another string of small buckets, only the first string will be coalesced.
This implementation works very well with the output generated by mod_autoindex though.
The number of iovecs handled by http_core is reduced to three from over a thousand for my
test case.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86355 13f79535-47bb-0310-9956-ffa450edef68
