get a long stream of small buckets, so that multiple concatenation
steps are required in a single pass through the brigade, re-use the
buckets from the previous temp brigade when creating the next one.
This allows us to avoid making yet another copy of the previously
concatenated data.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92197 13f79535-47bb-0310-9956-ffa450edef68
don't try to concatenate buffers if we already have at least
8KB of data ready to send. Instead, just split the brigade
and send what's currently in the iovec.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92196 13f79535-47bb-0310-9956-ffa450edef68
small buckets: It's possible for the temporary brigade to
contain more than one bucket. If this happens, we need to
recover the buckets after the first from the temporary brigade
before destroying it.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92176 13f79535-47bb-0310-9956-ffa450edef68
causing the server not to start.
previous method was to call exit(1) which would not fail
gracefully
PR:
Obtained from:
Submitted by:
Reviewed by: (Idea only Jeff Trawick)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92144 13f79535-47bb-0310-9956-ffa450edef68
sent, the core will send the first 16 buckets, regardless of how much
data there is. In the pathological case, this can cause a lot of 16
byte packets. Now, if we see less than AP_MIN_BYTES, we combine
all of the buckets into a single bucket to be sent in a later packet.
This can cause a lot of memory copies, but it eases our network traffic.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92097 13f79535-47bb-0310-9956-ffa450edef68
level filter that sets the timeout on the socket that is connected
to the client.
Thanks Greg Stein for seeing this bug.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92073 13f79535-47bb-0310-9956-ffa450edef68
allows filters such as mod_ssl to initialize a client connection
(ie handshake) before reading request data from the client.
PR:
Obtained from:
Submitted by: dougm
Reviewed by: wrowe
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92042 13f79535-47bb-0310-9956-ffa450edef68
many bugs. Instead, it is called where it used to be called. I have
abstracted some of the logic out of the lingering close so that it gets
the socket from the connection using the core's conn_config vector. This
is in anticipation of a change to use a hook for the lingering close,
which I hope to do soon.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91968 13f79535-47bb-0310-9956-ffa450edef68
current compiler errors. Basically, the core now puts the socket
in the conn_rec->conn_config vector. The proxy grabs that socket and
uses it where it used to use the client_socket field from the conn_rec.
Long-term, all of the direct socket communication needs to be removed,
and this should go through a filter stack. Short-term, this gets the
proxy working again.
I have tested http and connect, but I haven't looked at the FTP proxy,
although it does compile now.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91952 13f79535-47bb-0310-9956-ffa450edef68
make sure that we have a socket that the core controls if we do this,
but it is more correct.
Submitted by: Greg Stein
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91922 13f79535-47bb-0310-9956-ffa450edef68
takes the old ap_new_connection, and puts into the new core_create_conn
function. There is no good reason to have two functions to do this.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91890 13f79535-47bb-0310-9956-ffa450edef68
The first step is to remove the socket from the conn_rec,
the server now lives in a context that is passed to the
core's input and output filters. This forces us to be very
careful when adding calls that use the socket directly,
because the socket isn't available in most locations.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91887 13f79535-47bb-0310-9956-ffa450edef68
referential uri's, and updated the manual accordingly.
XXX There is a kludge here: XXX the port number from the client's Host:
header used to be tossed, and there is no clean mechanism to pass it
(in the request_rec) to other consumers. As the unparsed_uri structure
(which could avoid repeated parsing of URI, Host, Port etc) seems to be
mostly unused currently, I used that to pass the port.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91798 13f79535-47bb-0310-9956-ffa450edef68
server_rec->port is now set to zero, not 80. That allows for
run-time deduction of the correct server port (depending on
SSL/plain, and depending also on the current setting of
UseCanonicalName). This change makes redirections
work, even with https:// connections. [Martin Kraemer]
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91797 13f79535-47bb-0310-9956-ffa450edef68
with this and a request line that goes on forever, I now get:
[Wed Oct 31 17:45:45 2001] [error] [client 127.0.0.1] request failed:
URI too long
...in the error log, and a 414 in the access log.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91715 13f79535-47bb-0310-9956-ffa450edef68
looks like the line may never end.
This lets ap_getline determine whether there's excessive bytes or not,
depending on the size of its caller's buffers. If the buffer can accomodate
more bytes, ap_getline will continue to read.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91713 13f79535-47bb-0310-9956-ffa450edef68
The core input filter would happily consume all the data you gave it
in a header line, looking for that one LF. This patch limits that
"getline" functionality to HUGE_STRING_LEN (8192 bytes).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91711 13f79535-47bb-0310-9956-ffa450edef68
was that we forgot to check whether ctx->bb was empty, so when we pulled the
first bucket, it would be the sentinel, and we'd segfault trying to apr_bucket_read
the sentinel.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91641 13f79535-47bb-0310-9956-ffa450edef68
memcpy'ed the base into the merged per-dir config.
This certainly cleans up that function though, and I hope increases
it's legibility.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91624 13f79535-47bb-0310-9956-ffa450edef68
server. This change adds an optional hook, which allows modules
to gain control while the request is created if the proxy module
is loaded. The purpose of this hook is to allow modules to add
input and/or output filters to the request to the origin. While
I was at it, I made the core use this hook, so that proxy request
creation uses some of the code from the core. This can still be
greatly improved, but this is a good start.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91486 13f79535-47bb-0310-9956-ffa450edef68
of our brigade - which are in isolation okay. In this situation, they
must be removed by the call to APR_BRIGADE_NORMALIZE.
The way we partition the buckets means that we will never remove the
zero-length bucket from the head - causing an infinite loop. We read only
a single bucket now - previously partition with the blocking reads would
read multiple buckets - but it forced having a defined length which we
agreed was bogus.
Therefore, if we have a zero-length bucket at the head, we would then try
to partition and split at the zero-point of the brigade. That combination
doesn't actually remove the zero-length bucket - it is still there - causing
an infinite loop because we'll never go past the zero-length bucket.
This call was originally present in core_input_filter. I think it might
be better to fix partition/split/etc to eliminate a zero-length bucket
and skip it. But, I'm not 100% sure that needs to happen.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91412 13f79535-47bb-0310-9956-ffa450edef68
If the status code is anything other than SUCCESS for PEEK, it isn't
good. Just return the value.
(I thought it should be this, but I wasn't 100% sure. Peer review == good.)
Submitted by: Will Rowe
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91404 13f79535-47bb-0310-9956-ffa450edef68
Return with APR_EOF if we get EAGAIN.
(Whomever is calling this with PEEK should really be able to handle EOS
bucket rather than relying on error codes.)
Thanks to Greg Ames for pointing out this fubar.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91403 13f79535-47bb-0310-9956-ffa450edef68
(blocking or not).
apr_brigade_partition would do reading multiple times and that's
not really what we want (so I think).
This may speed up POST requests that were waiting for all of the
data to arrive before returning anything in blocking mode.
Reviewed by: Greg Stein, Ryan Bloom
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91322 13f79535-47bb-0310-9956-ffa450edef68
finite number of bytes (i.e. *readbytes > 0).
ap_brigade_partition does a blocking read. So, what we should do is
apr_bucket_read on the socket for non-blocking. If we get less than
what they asked for, that's okay and we should just return that amount.
If they were non-blocking, we should always be non-blocking.
Ryan, Greg, and others can figure out if ap_brigade_partition should
be tweaked to handle AP_NONBLOCK_READ natively. I'm of a mixed mind,
but this addresses the short term need.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91312 13f79535-47bb-0310-9956-ffa450edef68
is now a required directive, which tells Apache what port to
listen on. The ServerName directive has also been extended
to accept an optional port. If the port is specified to the
ServerName, the server will report that port whenever it
reports the port that it is listening on. This change was
made to ease configuration errors that stem from having a Port
directive, and a Listen directive. In that situation, the server
would only listen to the port specified by the Listen command,
which caused a lot of confusion to users.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91293 13f79535-47bb-0310-9956-ffa450edef68
- Clean up scopes and namings of certain variables
- Add comments about potentially bogus modes
- Consolidate a FOREACH loop into a single brigade_length call
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91191 13f79535-47bb-0310-9956-ffa450edef68
rearranging and rethinking some things. The net result is that the HTTP
filter is now a request filter and is now only responsible for HTTP things.
The core input filter is now responsible for handling all of the dirty work.
Highlights:
- Removes the dechunk filter and merges it with ap_http_filter (aka HTTP_IN).
The dechunk filter was incorrectly handling certain cases (trailers).
- Moves ap_http_filter from a connection filter to a request filter
to support the consolidation above (it needs header info).
- Change support code to allow the http_filter to be a
request filter (how the request is setup initially).
- Move most of the logic from HTTP_IN to CORE_IN (core_input_filter).
HTTP_IN is now only concerned about HTTP things. The core filter
is now responsible for returning data. It is impossible to
consolidate dechunk and http without this because HTTP_IN previously
buffered data. As Greg has suggested, it may make sense to write
some brigade functions that handle input (getline). It should be
fairly trivial to add these. Some of the calls in ap_http_filter
could be switched as well.
This is the original patch as submitted to dev@httpd on Monday, Sep.
24th. Additional comments and some minor tweaks done after that
submission are coming up next. This should allow people who reviewed
the original patch to see what has changed and review them piecemeal.
This test passes all current tests in httpd-test. Please perform
chicken sacrifices to verify that this hasn't blown up your favorite
input.
Reviewed by: Greg Stein, Ryan Bloom, and Cliff Woolley (buckets)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91189 13f79535-47bb-0310-9956-ffa450edef68
