content-length has already been set. If we don't, then we won't know if
the content-length has changed because some other filter changed the
length of the actual data. We also ALWAYS want to calculate the content
length if we get the whole brigade in the first call to this function.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86879 13f79535-47bb-0310-9956-ffa450edef68
if we decided to do so initially *and* we've seen all the data.
Prior to this change, for a http/1.1 request to mod_autoindex, the
unconditional call to ap_set_content_length() gave us the wrong
value (only taking into account the first brigade) and disabled
chunking.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86874 13f79535-47bb-0310-9956-ffa450edef68
functions to use it. This is onyl the start and I'll pause a while before
I continue in case people really hate this. The patch can be backed out and
all evidence will be removed, but I think this makes maintaining/developing
the code easier in the long term.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86870 13f79535-47bb-0310-9956-ffa450edef68
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
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
the first request if this is a keepalive connection. This allows us to
save the end of the first request until we have enough data from the
second request to make it worthwhile to send the responses. In order
to do this, we need to allocate mmap's from the connection pool instead
of the request pool. If we don't use the connection pool, then the mmap
is freed before the data is sent, because the mmap is freed at the end of
the first request.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86840 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
an incomplete version of the default_handler change.
This version gets always rid of the request body, regardless of the
method.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86809 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
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
