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
signed values in these integers, and we return the error codes directly,
so we should always report the number of bytes read/written correctly. If
we have an error, that is 0 bytes. If that is true, then using signed
values doesn't make any sense.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86857 13f79535-47bb-0310-9956-ffa450edef68
client or not. The reason for this, is that it allows us to log the
bytes sent to the client correctly. This also simplifies the
content-length filter a bit, by making it a single pass through the
brigade.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86852 13f79535-47bb-0310-9956-ffa450edef68
trace of that possibility from the code. First of all, there is nothing
that says you can only send one file bucket in a response, and second,
even if a handler sends a file, nothing says that it can't add text before
or after it too.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86846 13f79535-47bb-0310-9956-ffa450edef68
that works correctly right now is sockets, but pipes are coming next.
This also makes the http_header_filter do AP_MODE_PEEK correctly.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86830 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
if it gets a flush bucket. A generator of streaming content needs to send down
a flush bucket (e.g., by calling ap_rflush()) if it wants to send a partial
response to the client immediately.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86826 13f79535-47bb-0310-9956-ffa450edef68
CHUNK filter has been added. Otherwise, f->next won't be the
CHUNK filter and thus the first brigade won't be chunked
properly.
Reported by: wrowe
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86799 13f79535-47bb-0310-9956-ffa450edef68
(currently) we can't shorten the length of such a bucket by
setting e->length. (We could split and then remove the extra
bucket, but this seems cleaner. We may still want to have a
way to shorten a bucket, but there isn't a pressing need for
that at the moment.)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86790 13f79535-47bb-0310-9956-ffa450edef68
of bytes required for the headers for each request, and we just allocate
that number of bytes plus 100 extra. The extra 100 are a fudge factor,
because it is a bit difficult to compute the exact length for the
basic HTTP headers like date and the status line.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86781 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
. use %qx format instead of %llx for 64-bit integer (apr_time_t);
%llx prints as "%llx"
. pass offset and length to ap_bucket_create_mmap() so that byte
ranges work with mmaps (at least for a single range)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86777 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
ap_finalize_request_protocol on the main request, then we find the
last internally re-directed request, and send the EOS on that request.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86735 13f79535-47bb-0310-9956-ffa450edef68
ap_finalize_request_protocol()'s sole purpose in Apache 2.0 is to
send the EOS bucket. Probably need to reimplement ap_send_error_response()
to be consistent with ap_finalize...'s new mission.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86702 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
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
before today) so that we don't have a growth of these across many
pipelined requests.
http_filter() uses one brigade per connection which it reads into.
As it needs to deliver buckets to the caller, they are removed from
its brigade into the caller's brigade.
Submitted by: Ryan Bloom (but anything broken is my fault)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86632 13f79535-47bb-0310-9956-ffa450edef68
get rid of an unnecessary condition where we set ctx->b to NULL;
it was already NULL
ap_get_client_block():
"fix" the pool for the brigade used by ap_get_client_block() to
save its state; this allows pipelined requests to work
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86630 13f79535-47bb-0310-9956-ffa450edef68
when delivering body bytes, only deliver one block of data (however
much is returned by bucket read) instead of delivering the entire
body at once; this gets painful with a large body
make a note of an issue with the blocking state of the socket;
currently, the socket is non-blocking, but when reading body bytes
we should feel free to wait for body bytes until a timeout occurs;
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86628 13f79535-47bb-0310-9956-ffa450edef68
