and have those methods <limit>able in the httpd.conf. It uses
the same bit mask/shifted offset as the original HTTP methods
such as M_GET or M_POST, but expands the total bits from an int to
an ap_int64_t to handle more bits for new request methods than
an int provides.
Submitted by: Cody Sherr <csherr@covalent.net>
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89869 13f79535-47bb-0310-9956-ffa450edef68
for this solution. I'm easily convinced to choose AP_MAX_SENDFILE based
on any reasonable argument, provided it's smaller than 2^30 :-)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89714 13f79535-47bb-0310-9956-ffa450edef68
and apr_bucket_file_make().
*) Simplify mod_file_cache's sendfile_handler by taking advantage
the new ability of file buckets to handle files opened in XTHREAD
mode. [Also inlined some of the brigade construction stuff in
mod_file_cache's handlers to save a palloc() or two.]
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89438 13f79535-47bb-0310-9956-ffa450edef68
This patch was submitted by Ian Holsman. Greg revised some names, applied
the Apache style, and namespace-prefixed the public symbols. Minor bugfix in
the use of the hook implementation macro.
Submitted by: Ian Holsman <IanH@cnet.com>
Reviewed by: Greg Stein
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89364 13f79535-47bb-0310-9956-ffa450edef68
default_handler was using the subrequest pool for files and
MMAPs, even though the associated APR structures typically
live longer than the subrequest.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89354 13f79535-47bb-0310-9956-ffa450edef68
again. The problem is that the amount of data read from the network,
is not necessarily the amount of data returned from the filters. It is
possible for input filters to add bytes to the data read from the network.
To fix the original bug, I just removed the line from ap_get_client_block
that decremented r->remaining, we allow the http_filter to do that for
us.
I have also removed an incorrect comment.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89041 13f79535-47bb-0310-9956-ffa450edef68
which corresponded to r->remaining (in ap_get_client_block). However,
ap_get_client_block was *also* adjusting r->remaining. Net result was that
PUT (and probably POST) was broken. (at least on large inputs)
To fix it, I simply removed the indirection on "readbytes" for input
filters. There is no reason for them to return data (the brigade length is
the return length). This also simplifies a number of calls where people
needed to do &zero just to pass zero.
I also added a number of comments about operations and where things could be
improved, or are (semi) broken.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89008 13f79535-47bb-0310-9956-ffa450edef68
we have to use nbytes+flen when figuring out how much data we have,
and when looking at the fact that we have a buffer to save aside before
sending it, we also need to look at the length, to ensure that we aren't
saving too much.
Submitted by: Bill Stoddard and Ryan Bloom
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88972 13f79535-47bb-0310-9956-ffa450edef68
Delay the check for "too many items in an iovec" until we actually try to
put something in there. This allows that N+1 bucket to be an EOS, FLUSH,
FILE, or zero-length bucket without triggering a split. Only if that next
bucket has iovec data will a split be made.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88969 13f79535-47bb-0310-9956-ffa450edef68
connection pool. This solves a small resource leak that had us
not closing files until a connection was closed. In order to do
this, at the end of the core_output_filter, we loop through the
brigade and convert any data we have into a single HEAP bucket
that we know will survive clearing the request_rec.
Submitted by: Ryan Bloom, Justin Erenkrantz <jerenkrantz@ebuilt.com>,
Cliff Woolley
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88964 13f79535-47bb-0310-9956-ffa450edef68
determine how much data is returned to the previous filter. Prior to this
change, we used a field in the conn_rec to determine how much to return.
After this change, we use an argument to ap_get_brigade. This makes it
much more obvious how things work at all levels, so that module authors
can easily determine how much data is supposed to be returned to them.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88912 13f79535-47bb-0310-9956-ffa450edef68
told me I was wrong. I was wrong, and Greg was right. This commit
just moves the byterange filter and its related functions out of the core,
and puts them back in the HTTP specific module.
Submitted by: Greg Stein
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88815 13f79535-47bb-0310-9956-ffa450edef68
a request while it is being created. This hook is called for all
request_rec's, main request, sub request, and internal redirect.
When this hook is called, the the r->main, r->prev, r->next
pointers have been set, so modules can determine what kind of
request this is.
Currently, this is only used by the core module, but protocol modules
are going to need to have the ability to affect the request while it is
being read.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88532 13f79535-47bb-0310-9956-ffa450edef68
is core code, basically the default handler, the default input
and output filters, and all of the core configuration directives.
All of this code is required in order for the server to work, with or
without HTTP. The server is closer to working without the HTTP
module, although there is still more to do.
I tried to fix Windows, but somebody should probably make sure I did
it correctly.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88449 13f79535-47bb-0310-9956-ffa450edef68
