- 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
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
* eliminate some copying of sub-parts of the content type in analyze_ct()
* take advantage of the fact that we know the lengths of those sub-parts
in find_ct() to avoid having to recompute their length for concatenation
The charset handling code needs the same type of optimization eventually.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94900 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
our platform is not "case-blind." This matches 1.3 behavior and our
docs say that the extension argument is case-insensitive anyway.
This is case where the code fix is easier than the doc fix. =)
PR: 8223
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94789 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
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
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
