buffer when returning APR_ENOSPC. This prevents seg faults in
ap_get_mime_headers_core in an error path which handles headers that are too
long.
Submitted by: Jeff Trawick
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@99079 13f79535-47bb-0310-9956-ffa450edef68
branch from the mainline path.
It might be worthwhile to move all the getline error handling into a
separate function and be a little more i-cache friendly.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@97879 13f79535-47bb-0310-9956-ffa450edef68
too long. getline can return a smaller length that what it actually read in
that case.
The check for len > limit_fieldsize isn't needed, but we do need to insure
that getline actually allocated a buffer (and set len) in the case where
the first socket input buffer is already bigger than the limit.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@97863 13f79535-47bb-0310-9956-ffa450edef68
for ap_post_read_request, since that is the only opportunity for
modules to handle Expect extensions.
Obtained from: apache-1.3
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@97765 13f79535-47bb-0310-9956-ffa450edef68
ap_pass_brigade returns APR_SUCCESS
content-length needs to be alert to c->aborted so that it
doesn't keep trying to pass brigades down (otherwise, you get
errors writing to the network over and over and over and ...)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@97363 13f79535-47bb-0310-9956-ffa450edef68
when the content-length filter realizes that no new output will
be available for a while. This helps some streaming CGIs as
well as some other dynamically-generated content.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@97054 13f79535-47bb-0310-9956-ffa450edef68
is now case insensitive. Before, 'http/1.1' would silently be forced
to HTTP/1.0
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96857 13f79535-47bb-0310-9956-ffa450edef68
of content to clients
With this new code, the C-L filter will compute a content-length
if there's an EOS in the first brigade passed to it. For normal
static file requests, the response header will still include a C-L.
If there's no EOS in the first brigade passed to the C-L filter,
the filter will give up on setting the C-L header, in favor of
passing the data on to the next filter in a timely manner.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96557 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
for request header continuation lines. Instead, ap_get_mime_headers_core()
now sets aside each line of input until it sees the next line. If the
next line starts with a tab, it is appended to the previous one; otherwise,
the previous line is added to the request headers table.
This reduces the number of temporary buckets that must be created
and destroyed to read in a request.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95964 13f79535-47bb-0310-9956-ffa450edef68
read from pipe/socket buckets again if it got APR_EAGAIN from them
due to its use of APR_BRIGADE_FOREACH.
Submitted by: the gang on IRC
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95946 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
one was already sent.
mod_ext_filter performs some one-time processing when it sees EOS.
When it saw EOS more than once and a subsequent attempt to close a
file failed, it issued the log message described in PR 9644.
PR: 9644
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95595 13f79535-47bb-0310-9956-ffa450edef68
APR_BRIGADE_PREPEND instead, plus optimize away a bunch of repetitive
brigade destructions/creations by hanging onto ctx->saved even after
we empty it out.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94952 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
Garbage characters sometimes appeared after a legitimate folded header.
We weren't allocating an extra byte for the trailing null, or copying it,
when called from get_mime_headers (folding is in use, and ap_rgetline is
responsible for allocating memory). No need to worry about a trailing
LF - it's already been nuked.
I checked the partial line code to see if it had a similar bug. It looked
like it did, and that the code which trims the back end of the line would
run multiple times and whack innocent bytes. However, gdb showed that this
section of code appears to be dead due to input filter chain changes.
also, removed an assignment to a dead variable.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93804 13f79535-47bb-0310-9956-ffa450edef68
normal case worked OK, but due to the recursion and multiple exit points,
input bytes could go thru charset translation multiple times or not at all.
Suggested by: Justin Erenkrantz
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93776 13f79535-47bb-0310-9956-ffa450edef68
the complexity of trying to set the filter chain correctly, with the
side-effect of forcing us to walk the entire chain whenever we add
a filter. Since the filter chains are small, the decrease in
complexity is worth it.
Reviewed by: Allan Edwards
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93745 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
