there is still some bogosity in there (huge buffer allocs!), and some
optimizations to be made, but this appears to fix byterange handling.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86865 13f79535-47bb-0310-9956-ffa450edef68
Acrobat plug-in doesn't like it for some reason. This does work better
than what we currently have, because at least it returns all of the
requested data. This basically removes all BUFFs from the byte-range
code and removes all of the byte-range code from the default-handler.
Byte-ranges are now handled by a filter, which makes sense, and it allows
us to handle byte-ranges for all requests, not just files.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86864 13f79535-47bb-0310-9956-ffa450edef68
the byterange handling and ap_set_content_length().
[ ap_each_byterange() remains as an apr_size_t* so we don't mess up callers ]
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86860 13f79535-47bb-0310-9956-ffa450edef68
to use REQUEST_CHUNKED_DECHUNK.
Because of this change, the need for handle_request_body() is gone,
so we remove that as well.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86827 13f79535-47bb-0310-9956-ffa450edef68
we now create a single bucket that has all of the headers and send that.
One known issue is that this limits the headers to 8k, but it is a minor
patch to fix that.
This also stops us from exporting ap_send_header_field. This function no
longer makes sense to export.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86780 13f79535-47bb-0310-9956-ffa450edef68
the response when no content length is available and we can't use
chunked encoding.
This is going to be painful when the response body is huge, so I
suspect we'll have additional criteria in the future.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86775 13f79535-47bb-0310-9956-ffa450edef68
the EBCDIC support. They are noops on ASCII machines, so this
type of translation doesn't have to be surrounded by #ifdef
CHARSET_EBCDIC.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86751 13f79535-47bb-0310-9956-ffa450edef68
since we don't compute digests of filtered (e.g., translated)
response bodies this way anymore. (Note that we don't do it at
all at the present; somebody needs to write a filter to do so.)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86750 13f79535-47bb-0310-9956-ffa450edef68
BUFF. This has been tested, but all we can determine is that it doesn't
fail, not that it works. This needs to be tested much better.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86709 13f79535-47bb-0310-9956-ffa450edef68
fixed, but it is good enough for now. The idea is that headers shouldn't
flow through the BUFF anymore. Now, we have a header filter that is
called at the end of the request-filter chain. This filter writes the
headers directly to the connection filters.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86687 13f79535-47bb-0310-9956-ffa450edef68
casting away the const was absolutely wrong... the warnings were saying the
return value type needed to be fixed. did that and torched the casts.
who still thinks casts are a good idea? :-)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86668 13f79535-47bb-0310-9956-ffa450edef68
with this. To begin with, we store both the socket and the BUFF in the
conn_rec. Functions are free to use which ever they want, in the end all
of the data goes to the same place. This modifies all of the MPMs except
Windows. All of the Unix MPMs are working, but the others need to be
tested.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86651 13f79535-47bb-0310-9956-ffa450edef68
that lives across function calls during a single request. Change getline() to
take a request_rec parm (rather than a conn_rec) so we can access the
core_request_config.
This is in preparation for adding look-ahead functionality to getline(), so it
can support header line folding once again. I'm committing these changes first
so the core_request_config can be used elsewhere (i.e. ap_get_client_block).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86642 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 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
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
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
any modules symbol other than AP_MODULE_DECLARE_DATA, since module .h
files containing imports and exports imply something more sophisticated,
as the early mod_dav.c example illustrated.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86562 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
