to the service_init completion, expanded timeouts, moved SERVICE_STOPPED
message posting to the main thread since sometimes, in odd cirumstances,
our SCM thread wasn't resumed prior to termination, and ripped the code
for the stderr logs to use nt_eventlog.c instead. And generally tried
to make the code just a little bit more grokable [as if such a thing
is really possible.]
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93928 13f79535-47bb-0310-9956-ffa450edef68
can no longer hang on to the listeners after it checks that they are
free. Also, we cannot be checking listeners if we are using -k "config"
to alter the service config, since the service might be running as we
try this, and we cannot check the listeners in -k "restart", since we
are pretty certain they are owned by the running service we are about
to try restarting..
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93926 13f79535-47bb-0310-9956-ffa450edef68
listeners, the bottoms of peoples' shoes, etc.
Wait to set SO_REUSEADDR on Win32 until the parent is certain the
port is all ours.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93924 13f79535-47bb-0310-9956-ffa450edef68
call quick handler on a dirent subrequest. This fixes a nasty problem in
mod_cache where it was serving up content on a dirent subrequest.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93915 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
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
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
This patch changes nothing outside of that mode.
Also, why do we ever call apr_brigade_length() in the core? This doesn't
seem right to me, so here's a comment above the other call.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93736 13f79535-47bb-0310-9956-ffa450edef68
freelist patch. The remaining tabs go away for free with that patch.
Submitted by: Sander Striker
Reviewed by: Brian Pane
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93714 13f79535-47bb-0310-9956-ffa450edef68
added on !r->main requests. This led to infinite loop/SEGV when dealing
with anything that created a subreq.
(I don't think core_create_req is a good place for adding this filter.)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93694 13f79535-47bb-0310-9956-ffa450edef68
must set the r->output_filter to r->proto_output_filter. If we don't,
then as soon as we insert the request filter, the protocol filter will
be removed. This was causing headers to not be sent on some requests.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93692 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
solution ensures that we don't lose filters if they are added later than
we expect. The problem could be seen if a connection filter was added
after a request-based filter was added in the past. The problem was that
the request-based filters pointed to the first filter in the connection
record, so the new connection filter was never called. Now, all filters
are put on their correct filter lists, and we are sure to always update
all pointers when adding a filter.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93683 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
so make sure that it doesn't get left lying around. This tickled
a bug with mod_deflate and resulted in a bucket being compressed
more than once.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93610 13f79535-47bb-0310-9956-ffa450edef68
parent process, don't we?
This -was- post-fork() in 1.3, but with the massive restructuring,
we inadvertantly now whack the parent process.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93587 13f79535-47bb-0310-9956-ffa450edef68
code earlier today. With this mode, the Perchild MPM can finally be
fixed to work with filters. I have changed a comment in the core to make
it clear that this mode is required, but I have mentioned how dangerous
this mode is. Also add a comment to STATUS about my plans.
Hopefully I'll have some time this week to hack through the MPM.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93565 13f79535-47bb-0310-9956-ffa450edef68
fix a segfault and a window in which we could miss joining
newly-created threads
we can't try to signal workers if the worker queue hasn't
been initialized (or we segfault)
make sure the start thread is done creating threads before
we try to join; otherwise we can just miss some of them and
not be able to clean them up properly
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93561 13f79535-47bb-0310-9956-ffa450edef68
