type for the length than the brigade functions do. This moves the
len_read variable into the correct scope for the two times that it
is used, and defines it correctly for each scope.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91417 13f79535-47bb-0310-9956-ffa450edef68
be how many bytes we read. This trounces on the r->remaining value, so
we must use a local variable and subtract that from r->remaining after we
read.
Reviewed by: Aaron Bannert
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91413 13f79535-47bb-0310-9956-ffa450edef68
check_pipeline_flush(), making it think another request was available (when
it wasn't). Apache would avoid flushing the prior request and block on
reading the next request. (of course, the client wasn't sending the next
one, cuz it was still waiting for the results of the first one)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91366 13f79535-47bb-0310-9956-ffa450edef68
filter until after we have read the headers. This eliminates the status
hack that was in http_protocol.c and makes it all around better.
server/protocol.c now directly adds HTTP_IN filter - should we create a
specific hook for this? (Could we do this as a post_read_request hook?)
I'm not terribly sure, but let's move it down to the lowest possible
place in ap_read_request. We can change this detail later as we see fit.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91192 13f79535-47bb-0310-9956-ffa450edef68
rearranging and rethinking some things. The net result is that the HTTP
filter is now a request filter and is now only responsible for HTTP things.
The core input filter is now responsible for handling all of the dirty work.
Highlights:
- Removes the dechunk filter and merges it with ap_http_filter (aka HTTP_IN).
The dechunk filter was incorrectly handling certain cases (trailers).
- Moves ap_http_filter from a connection filter to a request filter
to support the consolidation above (it needs header info).
- Change support code to allow the http_filter to be a
request filter (how the request is setup initially).
- Move most of the logic from HTTP_IN to CORE_IN (core_input_filter).
HTTP_IN is now only concerned about HTTP things. The core filter
is now responsible for returning data. It is impossible to
consolidate dechunk and http without this because HTTP_IN previously
buffered data. As Greg has suggested, it may make sense to write
some brigade functions that handle input (getline). It should be
fairly trivial to add these. Some of the calls in ap_http_filter
could be switched as well.
This is the original patch as submitted to dev@httpd on Monday, Sep.
24th. Additional comments and some minor tweaks done after that
submission are coming up next. This should allow people who reviewed
the original patch to see what has changed and review them piecemeal.
This test passes all current tests in httpd-test. Please perform
chicken sacrifices to verify that this hasn't blown up your favorite
input.
Reviewed by: Greg Stein, Ryan Bloom, and Cliff Woolley (buckets)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91189 13f79535-47bb-0310-9956-ffa450edef68
attached to the proper pool. Otherwise, ctx->b would end up associated with
the request pool, and the SOCKET bucket from the CORE_IN filter would get
cleared at request end (thus the next request would go to CORE_IN for more
data and get APR_EOF, and figured there were no more requests).
This section of code was only triggered when a request had a body. The
symptom was closing the connection (even though it should have been a
keepalive) after the response was sent.
For more info, see Message-ID on dev@: <20010917061613.B466@lyra.org>
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91053 13f79535-47bb-0310-9956-ffa450edef68
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
