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
modules to not have to muck with the output_filter after it creates the
sub-request. Without this change, modules that create a sub-request have
to manually edit the output_filters, and therefore skip the sub-request
output_filter. If they skip the sub-request output_filter, then we end
up sending multiple EOS buckets to the core_output_filter.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87065 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
The basic problem is that when the pool is destroyed, the data will go
away unless it is in a pool bucket. If it is in a pool bucket, then the
data will be copied into a heap bucket when the pool is destroyed. This
becomes a real issue when we set some data off to the side to deal with
pipelined requests.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86947 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
sent the file yet. This also removes the send_http_headers call, because
that's a no-op so it doesn't make much sense to leave it in.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86938 13f79535-47bb-0310-9956-ffa450edef68
file_bucket read function now. If we try to read from a file bucket and
it makes sense to convert that bucket to an MMAP, that just happens.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86894 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
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
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
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
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
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
