to the EOR bucket destructor. Also, added some defensive code and comments
regarding r->pool lifetime to ap_process_http_connection.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@329664 13f79535-47bb-0310-9956-ffa450edef68
The core filter will NOT operate correctly across platforms
(even between Linux/Solaris) without setting up the conn->timeout,
so always apply the timeout when establishing the core filter.
The keep-alive-timeout is entirely an HTTP-ism, and needs to
move to the http protocol handler. Note #1; this isn't triggered
in the event mpm, but the event mpm introspects s->keep_alive_timeout
directly adding it to the pollset, so this is a non-sequitor.
Finally, once the headers are read, the named virtual host may
have a different (more/less permissive) timeout for the remainder
of the request body. This http-centric patch picks up that subtle
detail and can switch to a named-vhost timeout.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@306495 13f79535-47bb-0310-9956-ffa450edef68
Bumped mmn, and ap module cookie, for this function rename.
It's not a deprecation, as ap_http_method would be a lovely function
name sometime in the future: to determine what the function name implies.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@123882 13f79535-47bb-0310-9956-ffa450edef68
fix CLOSE_WAITs/leaked connections. The logic to deal with ap_read_request
failures got lost when merging in the HTTP pipelining fix. If ap_read_request
fails, the connection state should get set to CONN_STATE_LINGER so the MPM will
invoke lingering close. Test case: client sends a Connection: keepalive header
then closes the connection before the keepalive timeout pops.
Also add a comment to make the pipelining flow more obvious.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@106662 13f79535-47bb-0310-9956-ffa450edef68
Designed to minimize Apache's KeepAlive overhead.
This MPM depends on the current APR-trunk for new features added to
the apr_pollset interface. Currently the underlying operating
system must support KQueue or EPoll.
Status:
Should work as a drop in replacement for all non-ssl servers.
SSL Requests that use HTTP 1.1 Pipelining do not currently work.
Testing:
I have tested it with Linux 2.6, FreeBSD 5.2.1, and OS X 10.3.
Originally based on the patch by Greg Ames.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@105919 13f79535-47bb-0310-9956-ffa450edef68
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
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
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
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
expectations of their usage.
The reason that we should make this change now is that we have changed
the implied meaning of AP_FTYPE_HTTP_HEADER - some users of this should
be PROTOCOL while others should be CONTENT_SET. In order to clarify it,
toss all of the bogus names and force the filter writers to make sure
they understand what they are doing.
CONTENT_SET is new (horrible name - change if you have better idea), but
it indicates that it should run between RESOURCE and PROTOCOL.
mod_deflate is the ideal CONTENT_SET filter.
The changed type names are:
CONTENT is now RESOURCE.
HTTP_HEADER is now PROTOCOL. However, most filters that used HTTP_HEADER
may want CONTENT_SET. (Only things like POP and HTTP belong as PROTOCOL.)
MMN bump since all filters need to be recompiled due to filter reordering.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93756 13f79535-47bb-0310-9956-ffa450edef68
phase. This moves us to inserting the filters in the create_request
phase. This makes more sense, because now the protocol filters are attached
to the request as soon as possible. Previously, some requests never
called the insert_filters phase, so they don't get the filters. Think
redirects for reqeusts that never call insert_filters.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93750 13f79535-47bb-0310-9956-ffa450edef68
we would lose the extra filters. Now, if a filter is added, it is run.
Unfortunately, this can cause an infinite loop, or it can cause request
headers to appear twice. This commit removes two instances in the core
where we were inserting filters for a second and third time. The bug
was that error responses were causing infinite loops.
This also removes the reset_filters function, which did the exact
same thing as add_required_filters. The two functions were both called
in error conditions, which was part of what caused this bug.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93693 13f79535-47bb-0310-9956-ffa450edef68
this patch, the type wasn't too important, because all filters were
put on the same list. After this patch, the filter type is very important,
because there are three different types of filters, and they are all treated
differently, namely:
CONNECTION: Filters of this type are valid for the lifetime of this
connection.
PROTOCOL: Filters of this type are valid for the lifetime of this
request from the point of view of the client, this means
that the request is valid from the time that the request
is sent until the time that the response is received.
CONTENT: Filters of this type are valid for the time that this
content is used to satisfy a request. For simple requests,
this is identical to PROTOCOL, but internal redirects
and sub-requests can change the content without ending
the request.
It is important to realize that the three major types above are actually
broken down into smaller groups in the code, to ensure that the ordering
of filters is always correct.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93688 13f79535-47bb-0310-9956-ffa450edef68
client_socket from the conn_rec. Diffs from Ryan's patch include:
- rename the create_connection hook to install_transport_filters
- move the point of invocation of the hook till after the call to
after ap_update_vhost_given_ip to enable the hook to use vhost
config info in its decision making.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93087 13f79535-47bb-0310-9956-ffa450edef68
conn_rec. The create_connection_hook has a design flaw that prevents it
from making decisions based on vhost information.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93050 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
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
filter until after we have read the headers. This eliminates the status
hack that was in http_protocol.c and makes it all around better.
server/protocol.c now directly adds HTTP_IN filter - should we create a
specific hook for this? (Could we do this as a post_read_request hook?)
I'm not terribly sure, but let's move it down to the lowest possible
place in ap_read_request. We can change this detail later as we see fit.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91192 13f79535-47bb-0310-9956-ffa450edef68
