new LimitInternalRecursion directive configures limits of subsequent
internal redirects and nested subrequests, after which the request
will be aborted.
[William Rowe, Jeff Trawick, Andr� Malo]
PR: 19753 (and probably others)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@99911 13f79535-47bb-0310-9956-ffa450edef68
different request_recs after an ErrorDocument internal redirect failure.
examples: wrong Content-Type, garbled output from ebcdic servers due to
double charset translation
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96364 13f79535-47bb-0310-9956-ffa450edef68
present for internally redirected requests.
If HTTP_IN is present, r->proto_input_filters would have it, so adding it
twice is wrong.
PR: 10146
Reviewed by: Brian Pane
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95895 13f79535-47bb-0310-9956-ffa450edef68
AP_CONN_UNKNOWN
AP_CONN_CLOSE
AP_CONN_KEEPALIVE
This also fixes a problem where ap_discard_request_body would not discard
the body when keepalive was 0. This actually meant the keepalive status
was unknown *not* closed, but no one ever remembered that.
This problem was seen with mod_dav sending error responses (as reported by
Karl Fogel).
Suggested by: Greg "this isn't the '80s" Stein
Reviewed by: Greg Ames
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95891 13f79535-47bb-0310-9956-ffa450edef68
that mess with the status and which request_rec the rest of the function uses.
Submitted by: Justin Erenkrantz, Greg Ames
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95834 13f79535-47bb-0310-9956-ffa450edef68
- If an error would drop the connection, we do not return the top-level
error anymore as we will assume this new one takes precedence over the
original error. This also ensures that we will not read the input
body (which is the point of returning these special error messages in
the first place).
- The ap_discard_request_body return value in ap_die() must be checked
to make sure we don't encounter this recursive case and print two errors.
Kudos to Jeff Trawick for his sample input which pointed this out.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95426 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
fast_redirect, the filter would still point at the subreq - rather than
the original r. So, we must update any filters pointing at rr to be r.
This would cause lots of problems with mod_include with mod_dir requests
such as seen in PR 7966. mod_include would be unsetting the headers_out
of rr instead of r. But, we disassociate rr->headers_out and r->headers_out.
Therefore, the C-L header in r->headers_out would remain - even though it
bears no relation to what we will be outputting - causing problems.
This also now permits chunked-encoding of mod_dir/mod_include requests
which could never happen before and fixes the content-length problem
seen in PR 7966.
As hinted at in PR 7966, there is a race condition - if for some reason
the server stalls reading an included file (or even better, placing a
sleep in the cgi-bin script!), the invalid C-L may get propogated to the
client.
(Note that internal_internal_redirect has this same code fragment.)
PR: 7966
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94832 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
make sure that we don't have the sub_req_output_filter. This was
causing problems when there were multiple sub_Requests, and some should
have had the filter, but the last one shouldn't.
This fixes the final known bug in 2.0.35
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94470 13f79535-47bb-0310-9956-ffa450edef68
the http_headers output filter. Now we will always point every filter at
the 'redirected' request, e.g. the actual error message response rather
than the request that failed.
Reviewed by: JimJag, Rbb, DougM
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94467 13f79535-47bb-0310-9956-ffa450edef68
The problem was that the internal_fast_redirect removed the SUB_REQ
filter, but we are still in a sub_request. The solution is to have the
fast_internal_Redirect function check if we are in a sub_Request and
re-add the filter if we are.
Submitted by: Ryan Bloom, Greg Ames, Jeff Trawick, and Will Rowe
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94456 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
quick handlers to optionally do a lookup rather than actually
serve content. This is the first of several changes required fix
several problems with how quick handlers work with subrequests.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94240 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
call quick handler on a dirent subrequest. This fixes a nasty problem in
mod_cache where it was serving up content on a dirent subrequest.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93915 13f79535-47bb-0310-9956-ffa450edef68
was required to make sure that the sub request had the correct filters
when we went send the error page. With the new filter insertion logic,
this is no longer necessary.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93710 13f79535-47bb-0310-9956-ffa450edef68
were not getting the correct filters. This is done by creating a location
in the request rec that holds protocol level filters. Protocol level
filters survive for one request, from the time the request is received
from the user to the time the response is sent. r->output_filters now
stores the request level filters, which are only valid for the lifetime
of one request_rec.
This patch works, but it is not complete. The second half of the problem
is that add_any_filter doesn't check where it puts the filters that it
adds, so it is possible for filters to be put on this wrong list, and
for filters to be lost completely during request processing. That half
of the fix will be coming in the next day or so.
Submitted by: Will Rowe, Justin Erenkrantz, Ryan Bloom
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93682 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
when sending a negotiated ErrorDocument because the required
filters were attached to the wrong request_rec.
Submitted by: John Sterling <sterling@covalent.net>
Reviewed by: Justin Erenkrantz, Cliff Woolley
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91900 13f79535-47bb-0310-9956-ffa450edef68
Without this, we see an extra socket read + timeout on POSTs. If the client
sends in another request, we loop consuming memory.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91695 13f79535-47bb-0310-9956-ffa450edef68
caller -- ap_process_request_internal() -- catches that and returns
OK to its caller -- ap_process_request(). But ap_process_request(),
seeing OK, tries to run a handler. It needs to skip that if the
request was completed in ap_process_request_internal().
Reviewed by: William A. Rowe, Jr.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91095 13f79535-47bb-0310-9956-ffa450edef68
strings to numbers in places where the methods are known at compile
time.
(Justin fixed the va_end() call to be correct.)
Submitted by: Brian Pane <bpane@pacbell.net>
Reviewed by: Justin Erenkrantz
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91078 13f79535-47bb-0310-9956-ffa450edef68
now served out (r) info instead of the (rnew) info. Made for nasty
cyclic loops in mod_dir :(
It looks like this works once again. I'll post completed deltas to
the list ASAP.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90838 13f79535-47bb-0310-9956-ffa450edef68
from the primary request, redirects and sub-requests.
This will significantly reduce opporunities for inconsistancy (such
as Ian observed, and as I repaired only a month ago.)
This promotes process_request_internal to an ap_ namespace protected
entity in server/request.c (from it's old home in http/http_request.c)
since this fn has no http specifics.
Reviewed (in concept): Cliff Woolley, Ian Holsman
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90832 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
