before ap_set_keepalive is called. need to remove this check
in order for keepalives to work.
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90700 13f79535-47bb-0310-9956-ffa450edef68
the directory_walk and file_walk for non-file requests. TRACE
shortcut moved to http_protocol.c as APR_HOOK_MIDDLE, and the
directory_walk/file_walk happen as APR_HOOK_VERY_LAST in core.c.
A seperate patch to mod_proxy is required to short circuit both the
TRACE and directory_walk/file_walk stuff. That patch is next.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90665 13f79535-47bb-0310-9956-ffa450edef68
containing any bucket that cannot be copied natively (ie, pipe or socket
buckets).
Before, we were reading that bucket to morph it to a heap bucket and then
taking the str that heap bucket points to and placing it in a second,
completely separate heap bucket. That means we'd have two apr_bucket/
apr_bucket_heap pairs each with a refcount of 1 (rather than two apr_buckets
and a single apr_bucket_heap with a refcount of 2). str would then be
doubly-freed when the second of those two buckets was destroyed.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90648 13f79535-47bb-0310-9956-ffa450edef68
add support for renegotiation during the Access hook
this requires hooking into the read and write SSL BIOs in order to
flush data to the client and read from the filter chain
this also requires that the ssl filters become "aware" that
renegotitation is in progress so that the BIOs are left alone for
SSL_renegotiate/SSL_do_handshake in ssl_hook_Access to deal with
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90185 13f79535-47bb-0310-9956-ffa450edef68
add a new macro, called APR_BRIGADE_NORMALIZE. This macro searches
all the buckets, and removes any zero length bucket. They we can
just use APR_BRIGADE_EMPTY to determine if our brigade has any data,
and we can quickly call ap_get_brigade if it doesn't.
Doug, please throw your battery of tests at this to make sure it works.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90070 13f79535-47bb-0310-9956-ffa450edef68
brigade has data. To that end, if we have just expanded ctx->b, we need
to concat ctx->b to the end of b, so that b has something to pass
back to the previous filter.
This fixes the problem with the proxy not proxying non-keepalive
connections.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90046 13f79535-47bb-0310-9956-ffa450edef68
all data from the socket until the socket is closed. This has been
used to proxy www.google.com successfully, but it doesn't return anything
when used with www.yahoo.com. Still debugging that problem.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90044 13f79535-47bb-0310-9956-ffa450edef68
apr_brigade_partition. In order to do this cleanly, I had to make
some changes to the apr_brigade_partition API, so this also adds fixes
all of the calls to that function throughout the server.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90029 13f79535-47bb-0310-9956-ffa450edef68
apr_brigade_partition function. This should also remove a warning from
the Windows build, because apr_off_t and apr_size_t aren't the same
size.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89997 13f79535-47bb-0310-9956-ffa450edef68
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
compliance changes. Note I've left alone the <P> tags, since they
are abused, misused, potentially unsalvageable and certainly more
effort than I care to expend in my quest for brainless end of week
keyboard exercise.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89753 13f79535-47bb-0310-9956-ffa450edef68
header_filter will stay installed in the filter chain when processing
HEAD requests to intercept and discard content bodys sent by poorly
written handlers. This work also points out the need for an optimization
in the content_length filter to not split the brigade if the next bucket
in the brigade is an EOS.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89679 13f79535-47bb-0310-9956-ffa450edef68
where HEAD response headers were being repeated twice for
files greater than 32K bytes (4*AP_MIN_BYTES_TO_WRITE). This
problem in the http_header filter was exposed by the recent rewrite
of the content_length filter.
[Taketo Kabe, Bill Stoddard]
PR: 8037
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89676 13f79535-47bb-0310-9956-ffa450edef68
TLSFilter gets wiped out, breaking any response that comes through ap_die
(including the frequent '304 not modified')
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89601 13f79535-47bb-0310-9956-ffa450edef68
apr_brigade_puts(). There is still some redundancy--it'd be ideal if there
were an apr_pstrcat() variant that returned the length of the string since
it computes it (twice) anyway so we didn't have to do it yet again. Until
such a beast exists, computing the length three times is better than four.
:-/
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89516 13f79535-47bb-0310-9956-ffa450edef68
* did some code cleanups/optimizations in that function.
* updated Apache's byterange filter to handle the new prototype. added
error handling to the byterange filter should apr_brigade_partition()
ever fail, which it never will unless somebody either removes the earlier
call to apr_brigade_length() for some unknown reason or invents a new
bucket type that is of a predetermined length but which cannot be split
natively (or which has a split that might fail). might as well be
future-proof.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89363 13f79535-47bb-0310-9956-ffa450edef68
parms to form_header_field() and it overlaid some vhost structures,
resulting in a segfault in check_hostalias().
[Greg Ames, Jeff Trawick]
Note: Not being familiar with the TRACE method I compared the 2.0
output with 1.3.9 output. The only difference is that with 2.0 we
get a Content-Length header field.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89138 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
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
request, then the byterange filter should not try to redo the
work. The most common case of this happening, is a byterange
request going through the proxy, and the origin server handles
the byterange request. The proxy should ignore it.
Submitted by: Graham Leggett <minfrin@sharp.fm>
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88873 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
(header) through the filter stack, which just wrapped that response in
another set of headers.
Instead, just set the Allow header and return. The EOS will then flush that
header with the rest of the data through the header filter, and generate the
proper response.
Also, cleaned out the unused header_filter_ctx and the "len" variable from
the header filter, and added some comments here and there.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88600 13f79535-47bb-0310-9956-ffa450edef68
