are guaranteed to support 100 - Continue logic without any
intervention.
This requires some reshuffling of the code in http_protocol.c so
that some static declarations are available early enough in the
code so that ap_http_filter can access them.
Note that we can not read the chunk until after (possibly) sending the
100.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94668 13f79535-47bb-0310-9956-ffa450edef68
The equivalent logic was deleted when request filters were renamed to
RESOURCE filters. This fixes the seg faults that sometimes happen on
daedalus after a bogus 416 HTTP response is generated.
In this case, includes_filter had found an <!--#include virtual > tag, and
sent a brigade representing the data before it down the filter chain. The
byterange filter generated the bogus 416. ap_send_error_response essentially
starts over with a new response, but it didn't do anything to clean up the
filter chain. So the same instance of the includes_filter got driven from the
top with the canned error text and and EOS bucket, which confused the heck
out of it. It inserted a sentinel from the original brigade into the
error page brigade, causing problems further down the filter chain.
Submitted by: Greg Ames, Jeff Trawick
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94662 13f79535-47bb-0310-9956-ffa450edef68
Add an allocator-passing mechanism throughout the bucket brigades API.
From Apache's standpoint, the apr_bucket_alloc_t* used throughout a given
connection is stored in the conn_rec by the create_connection hook. That
means it's the MPM's job to optimize recycling of apr_bucket_alloc_t's --
the MPM must ensure that no two threads can ever use the same one at the
same time, for instance.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94304 13f79535-47bb-0310-9956-ffa450edef68
the original site Server header with it's own, which is not
allowed by RFC2616. Fixed.
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94133 13f79535-47bb-0310-9956-ffa450edef68
1. rename ap_rset_content_type to ap_set_content_type
2. reverse the arguments on the call to aligh with ap_set_content_length
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94056 13f79535-47bb-0310-9956-ffa450edef68
this is friendlier to callers and r->content_type is const char *
too so it isn't harmful
this fixes a fatal compile error with AIX+xlc
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94051 13f79535-47bb-0310-9956-ffa450edef68
now that it has an RFC. At the same time, I revamped a good chunk of
the name <-> number mapping code in http_protocol.c
* add M_FOO constants for the new RFC 3253 (DeltaV) methods. label
where each of the builtin methods comes from.
* moved METHOD_NUMBER_FIRST/LAST from http_protocol.h into
http_protocol.c since they weren't used anywhere else and they
weren't namespace-protected.
* create register_one_method() and use it to insert all builtin
methods (at _init() time) and extended methods into the registry.
* add a lookup_builtin_method() to quickly map a method name to a
builtin method number.
* rebuild ap_method_number_of() to use the new lookup function.
* revamp ap_method_name_of() to use the registry to locate the name
for any method number. add a pool argument (no callers in the core
code needed to be updated)
* revamp make_allow() to deal with the new method numbers and all
extended methods.
* in mod_dav, use the new method numbers rather than registering the
DeltaV methods.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94015 13f79535-47bb-0310-9956-ffa450edef68
we would lose the extra filters. Now, if a filter is added, it is run.
Unfortunately, this can cause an infinite loop, or it can cause request
headers to appear twice. This commit removes two instances in the core
where we were inserting filters for a second and third time. The bug
was that error responses were causing infinite loops.
This also removes the reset_filters function, which did the exact
same thing as add_required_filters. The two functions were both called
in error conditions, which was part of what caused this bug.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93693 13f79535-47bb-0310-9956-ffa450edef68
logging.
The content length filter seems to track bytes_sent properly regardless
of HTTP version. The HTTP header filter knows not to send C-L (or any
headers) to this client.
showstoppers--;
(Also fix typo of my last name in CHANGES...)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93588 13f79535-47bb-0310-9956-ffa450edef68
I want to see a core. 0 bytes reads are fine. Grr.
(I'm so tempted to throw this assert out, but if we get -1 length
brigades back, we're gonna be screwed.)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93202 13f79535-47bb-0310-9956-ffa450edef68
If you need the length, you should be using apr_brigade_length. This is
much more consistent. Of all the places that call ap_get_brigade, only
one (ap_http_filter) needs the length. This makes it now possible to
pass constants down without assigning them to a temporary variable first.
Also:
- Change proxy_ftp to use EXHAUSTIVE mode (didn't catch its -1 before)
- Fix buglet in mod_ssl that would cause it to return too much data in
some circumstances
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93014 13f79535-47bb-0310-9956-ffa450edef68
separate from the input filter mode type.
We also no longer look at readbytes to determine the method of
filter operation. This makes the use of filters more obvious and
allows a wider range of options for input filters modes.
To start with, the new input filter modes are:
AP_MODE_READBYTES (no more than *readbytes returned)
AP_MODE_GETLINE (old *readbytes == 0 case)
AP_MODE_EATCRLF (old AP_MODE_PEEK)
AP_MODE_SPECULATIVE (will be used in a future ap_getline rewrite)
AP_MODE_EXHAUSTIVE (old *readbytes == -1 case)
AP_MODE_INIT (special case for NNTP over SSL)
The block parameter is an apr_read_type_e: APR_BLOCK_READ, APR_NONBLOCK_READ
This also allows cleanup of mod_ssl's handling in the getline case.
Reviewed by: Ryan Bloom (concept), Greg Stein (concept)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92928 13f79535-47bb-0310-9956-ffa450edef68
from the request. To do this, we also need to register all of the new/custom
methods that mod_dav recognizes.
Note: this fixes a bug where a method (e.g. REPORT) would appear in a
Limit(Except) directive and Apache would register the method. The method
number in the request would then be something *other* than M_INVALID, which
threw off mod_dav's tests.
Submitted by: Sander Striker <striker@apache.org>
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92764 13f79535-47bb-0310-9956-ffa450edef68
directive when reading a proxy response. We should bypass LimitRequestBody
activities when handling a response from the proxied server.
I don't think this will circumvent requestbody checking on a large request
coming into the server that is destined to be proxied. (not tested though).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92722 13f79535-47bb-0310-9956-ffa450edef68
ap_*_client_block to ap_http_filter (aka HTTP_IN). This is the
only appropriate place for limit checking to occur (otherwise,
chunked input is not correctly limited).
Also changed the type of limit_req_body to apr_off_t to match the
other types inside of HTTP_IN. Also made the strtol call for
limit_req_body a bit more robust.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92700 13f79535-47bb-0310-9956-ffa450edef68
ap_get_client_block.
There were two len_read vars (each of different types), so the outer one
was shadowed - move it to the correct scope.
Move apr_bucket* old declaration inside of the loop so it is obvious
what its scope is.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91806 13f79535-47bb-0310-9956-ffa450edef68
calling ap_get_brigade. This takes care of the loop with short request bodies
seen on 2.0.27.
This eliminates the use of r->remaining within ap_get_client_block.
http_filter has the equivalent in its context. r->remaining is
still used in ap_setup_client_block for a "body too long" check. But that
check can't cover chunked bodies, so it probably should happen elsewhere.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91785 13f79535-47bb-0310-9956-ffa450edef68
I thought these other changes needed to go in; Namely that we don't
need to check if the brigade is empty twice in the loop, just once.
Added a comment for good measure.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91478 13f79535-47bb-0310-9956-ffa450edef68
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
