profiling I've done, the read() in apr_read() would always fail with
EAGAIN. This will send the thread directly to select to wait for the
next request.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95968 13f79535-47bb-0310-9956-ffa450edef68
arbitrary code before the handlers are invoked.
This resolves an issue with incorrect 304s on If-Modified-Since mod_include
requests since ap_meets_conditions() is not aware that this is a dynamic
request and it is not possible to satisfy 304 for these requests (unless
xbithack full is on, of course). When mod_include runs as a filter, it is
too late to set any flag since the handler is responsible for calling
ap_meets_conditions(), which it should do before generating any data.
If a module doesn't need to run such arbitrary code, it can just pass NULL
as the argument and all is well.
PR: 9673
Reviewed by: Ryan Bloom and others
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95906 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
connection->keepalive is false. This works in conjunction with
ap_die which resets connection->keepalive any time
ap_status_drops_connection is true. The latter is explicity tested
here in case ap_die isn't involved.
Submitted by: Justin Erenkrantz, Greg Ames
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95882 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
error return value already indicated that errno was set. Also, we might
as well accept any error or junk remaining in the field as a parse error.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95743 13f79535-47bb-0310-9956-ffa450edef68
solidified after this code was originally written. Namely:
- AP_MODE_READBYTES will only return a brigade representing AT MOST bytes
of data. It can NOT return MORE than requested.
- APR_BLOCK_READ is respected - it is considered a design error of a filter
if it returns without reading something.
- apr_brigade_flatten is available to do the heavy lifting of the copying
into a flat buffer (as hinted at by the removed comment).
Tested with httpd-test.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95721 13f79535-47bb-0310-9956-ffa450edef68
server_rec->keep_alive_timeout in apr_time_interval_t format (in apr
units, whatever they be), as both values exist to pass into APR, and
all APR timeouts are in apr_time_t.
Reviewed by: Cliff Woolley
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95623 13f79535-47bb-0310-9956-ffa450edef68
same request. Essentially, ap_http_filter keeps track of whether
it has sent an EOS bucket up the stack, if so, it will only ever
send an EOS bucket for this request.
Submitted by: Ryan Bloom, Justin Erenkrantz, Greg Stein
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95505 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
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
