that does not add a content-length. For example, mod_autoindex doesn't
set a content-length, but the byterange filter requires one. We fix this
by computing the content-length in the byterange filter.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87389 13f79535-47bb-0310-9956-ffa450edef68
blocking and non-blocking reads. This allows us to use the mode parameter
passed to a filter to read from the bucket correctly.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87256 13f79535-47bb-0310-9956-ffa450edef68
files need to specifically include stdio.h, or a particular apr_*.h
header.
*) Adjust callers of apr_create_process() to deal with the extra "const"
*) Add "const" to args of ap_os_create_privileged_process()
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87080 13f79535-47bb-0310-9956-ffa450edef68
if/when we compute the content-length. There are just a few cases now:
1) We already have all the data
2) We don't have all the data and:
2a) This is a 1.1 request but we can't chunk
2b) The is a keep-alive request
In the future, we probably want to modify this to not
be a keep-alive request.
This filter always buffers 9K of data. The reason is simple, the core will
buffer 9K at a time anyway, and there is a chance that we may get the end
of the request before we hit 9K. This increases our chances of being able
to send a c-l.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87055 13f79535-47bb-0310-9956-ffa450edef68
ap_send_error_response to the http_header filter. The reason for the move,
is that the header filter takes care of all header processing now. Without
this change, we were sending garbage data to the client whenever we sent
304 responses.
Submitted by: Brian Havard and Ryan Bloom
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87003 13f79535-47bb-0310-9956-ffa450edef68
ugly, but it does proxy pages. This even fixes the content-type bug
that I introduced yesterday sometime. As soon as BUFF is removed from
the FTP proxy, the buff.c and buff.h files need to go away.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86988 13f79535-47bb-0310-9956-ffa450edef68
the content-length is 0. The problem is that the C-L on a HEAD response
has to be the correct C-L, but if a handler returns saying the handled
the request without sending data, the core sends an EOS down the filter
stack, and we compute a 0 C-L.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86976 13f79535-47bb-0310-9956-ffa450edef68
chance to compute the proper content-length before we try to send a set
of headers. If a handler wants to ignore the HEAD method, then it can
either just return from the handler function or pass an EOS bucket down
the filter stack. Either method will still get the headers sent to the
client.
This change allows handlers to actually run the request like it is a GET
request. The core itself will then ensure that no body is sent. This
allows us to get more information about the request before sending out the
headers for the HEAD request.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86954 13f79535-47bb-0310-9956-ffa450edef68
header file. The only time that the C-L should be zero is if there is
no body. Zero is a valid content-length, but the only time that we ever
really send it is on a HEAD request right now, and that is incorrect.
The HEAD response should have the actual content's length.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86953 13f79535-47bb-0310-9956-ffa450edef68
mod_autoindex funky chunking behaviour until the ap_r* routines are reimplemented, at which
time this filter should probably go away.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86943 13f79535-47bb-0310-9956-ffa450edef68
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
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
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
