the error would be sent to the client *twice* because both the filter
and the core would trigger error responses.
The problem is that the filters have already handled some errors (say 413)
and due to the ap_get_client_block API, the error was morphed into 400.
Therefore, ap_discard_request_body must use brigades directly rather than
the ap_get_client_block API so that any potential errors are not dropped.
The special value AP_FILTER_ERROR indicates that the lower level has
already dealt with this problem (ap_die() will realize this). Otherwise,
we'll error with HTTP_BAD_REQUEST and ap_die() will take it from there.
This also prevents needless memory copies when we are just going to
discard it anyway.
Thanks to Cliff Woolley who found this wacky problem.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95424 13f79535-47bb-0310-9956-ffa450edef68
state and we hit some other error (like permission failure) causing
an internal redirect causing us to reevaluate the input buffers
(for discarding the request body).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95419 13f79535-47bb-0310-9956-ffa450edef68
- Fix bucket lifetimes so that they don't live longer than their brigades.
That's not nice.
- Simplify some usage of f->r->connection to f->c in the bucket creation
calls.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95416 13f79535-47bb-0310-9956-ffa450edef68
possible that there can be different behavior at the protocol level if
request_rec isn't really a request but a response.
This stems from the fact that request bodies must be indicated by
Content-Length or Transfer-Encoding, but response bodies do not. The
recent change to ap_http_filter to return EOS if there isn't a body broke
proxy. Therefore, there must be some way for the proxy to indicate that
this is a response. Accordingly, ap_http_filter can allow the BODY_NONE
iff this is a response.
Since r->proxyreq is set to PROXYREQ_PROXY even for the original request
from the client, that value isn't sufficient. Hence, the introduction of
PROXYREQ_RESPONSE.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95390 13f79535-47bb-0310-9956-ffa450edef68
- If get_chunk_size() returns a negative number, that probably implies
an overflow. So, create a 413 error and pass it to the output filters.
- Modify ap_discard_request_body() to return OK quickly if we're a subreq
or our status code implies that we will be dropping the connection.
- Modify ap_die() so that if the new status implies that we will drop
the connection, that we correctly indicate that we can not keepalive
this connection. (Without this, the error is returned, but the connection
is not closed.)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95331 13f79535-47bb-0310-9956-ffa450edef68
have a predetermined C-L - such as data that passes through mod_include.
Previously, these requests would generate 416 since when the byterange
filter ran, r->clength would be 0. r->clength is only guaranteed to
be valid after C-L filter is run, but we need C-L to run after us so
that our data can have a proper C-L returned. So, we need to rearrange
the code so that we can deal with this case.
Highlights:
- Remove r->boundary since it is possible to have this self-contained in
boundary's ctx. (May require MMN bump?)
- Remove call to parse_byteranges in ap_set_byterange since this would
wrongly return -1 for dynamic responses. We have to wait until we
see EOS to call parse_byteranges.
- Move bound_head computation inside the num_parts == 2 check.
- Change a NULL brigade check to APR_BRIGADE_EMPTY
- Move the 416 error return to after we've run through all ranges and
found none of them to be valid.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94942 13f79535-47bb-0310-9956-ffa450edef68
would mean that downgraded requests were ineligible for force-response
checks.
Previously, 1.3 would do the downgrade in process_request_internal and
then the force-response later on in basic_http_header.
PR: 8357
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94771 13f79535-47bb-0310-9956-ffa450edef68
instead of ap_getline - this prevents some odd looping issues that
can cause problems.
Also, when we call get_mime_headers to read the trailers, we need
to reset our ctx->state to BODY_NONE - there should only be MIME-header
information (followed by a blank CRLF line) - and we don't know
how much data there will be - so it is by definition BODY_NONE.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94704 13f79535-47bb-0310-9956-ffa450edef68
If we do not know a C-T for a subreq, we *must* propogate that
non-knowledge upwards to the main request.
Previously, if you used a DirectoryIndex with a file without a C-T (say
.shtml without AddType), the r->content_type will be kept as
httpd/unix-directory when we promoted the subreq in mod_dir. Since there
would be no handler on this file, ap_invoke_handler (config.c:355) would
set the handler to be httpd/unix-directory (which was the old C-T of the
dir). This would then trigger the handler to become httpd/unix-directory.
mod_autoindex would then try to serve the request. But, the filename
was propogated upwards by mod_dir's DirectoryIndex via
internal_fast_redirect - it would then return a 403 trying to generate a
mod_autoindex page for a file.
Now, we will use ap_default_type() which is correct.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94676 13f79535-47bb-0310-9956-ffa450edef68
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
