for our later call to ap_meets_conditions a few lines above. Having it put
in the merge table will fail as merge and r->err_headers_out get merged
AFTER our call to ap_meets_conditions. Besides of this having multiple
ETag headers (or a merged version of them) does not seem to make sense.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@541974 13f79535-47bb-0310-9956-ffa450edef68
operation. This ensures the exported (Studio 97 generated) .mak
files create a usable Apache directly from the VC 8 (Studio 2005)
command line environment.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@495126 13f79535-47bb-0310-9956-ffa450edef68
ap_mpm_run(), then destroy pmain when exiting ap_mpm_run().
The expected call to ap_run_child_init() appears to have been removed
in r89640. However, that call should presumably still be made once per
process, as in other single-process MPMs like the netware MPM.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@491922 13f79535-47bb-0310-9956-ffa450edef68
always returns APR_INCOMPLETE on Unix platforms in the case that the
call to the native stat / lstat did not fail. So we can safely assume
that the stat / lstat call has been successful in this case.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@491297 13f79535-47bb-0310-9956-ffa450edef68
default command-line build to \Apache2x directory, and name service Apache2.x
(which means this doesn't need to change over and over as trunk becomes 2.5, 2.7 etc.)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@483555 13f79535-47bb-0310-9956-ffa450edef68
use the already-open stderr file object rather than opening a new one.
Submitted by: Tom Donovan <Tom.Donovan acm.org>
PR: 40476
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@467338 13f79535-47bb-0310-9956-ffa450edef68
locking method and the lockfile location, I never
liked how AcceptMutex was linked to LockFile. This
seemed unnecessary. Much better to have AcceptMutex
do both as well. Plus, now that we will likely see
other modules require a "standard" way of setting
mutexes, why not have Apache provide that as
an API of sorts.
Anyway, LockFile is now depreciated and AcceptMutex
is now SSLMutex-like. We also provide a short
function that "parses" out a mutex parameter
and strips out the mechanism and lockfile location.
AcceptMutex and SSLMutex is this capability.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@467326 13f79535-47bb-0310-9956-ffa450edef68
listen sockets in some configurations with multiple generic Listen
directives.
The logic in error is that which prunes out generic IPv4 listening
sockets when we already have a v4-mapped generic IPv6 listening
socket for the same port.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@467034 13f79535-47bb-0310-9956-ffa450edef68
the first bucket from the brigade, finds it not to be a FILE
bucket and barfs. The fix is to pass a bucket rather than a brigade.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@462580 13f79535-47bb-0310-9956-ffa450edef68
that the new child's stderr is not a pipe to an old piped logger:
* server/log.c (log_child): Add "dummy_stderr" parameter; if set,
duplicate stdout as the stderr for the child.
(open_error_log): Add "is_main" parameter; use dummy stderr for logger
for main server only.
(ap_open_logs, ap_open_piped_log): Adjust for new open_error_log()/
log_child() parameters.
PR: 40651
Submitted by: jorton, rpluem
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@452431 13f79535-47bb-0310-9956-ffa450edef68
a cleanup function that is registered with the request pool.
eor_bucket_destroy only destroys the request pool if there is still a request
at this point of time which triggers the call of the cleanup function.
This is needed as the eor bucket could be (and usually is) allocated from
a pool different from the request pool (the connection pool in this case).
This can lead to situations where eor_bucket_destroy is called at a point of
time when the request pool had been already destroyed. But the status update
and the transaction logging rely on the request pool.
In practise this happens with the worker MPM if the client refuses to read
the response from the handler. Then the unsent data (including the
eor bucket) remains in a brigade allocated from the connection pool which
is the parent of the request pool. This brigade is cleaned up during the
cleanup of the ptrans pool in worker_thread. As the request pool gets
destroyed during this cleanup operation *before* the brigade gets cleaned up
eor_bucket_destroy starts the status update and the transaction logging with
a destroyed request pool which leads to a segfault.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@451279 13f79535-47bb-0310-9956-ffa450edef68
If a handler returns a value that is neither reserved nor a valid
HTTP response code, log an error and substitute HTTP_INTERNAL_SERVER_ERROR.
Allow a handler to override this explicitly by setting a note.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@448711 13f79535-47bb-0310-9956-ffa450edef68
ap_get_server_description().
High-level summary:
The full server version information is now included in the error log at
startup as well as server status reports, irrespective of the setting
of the ServerTokens directive.
Third-party modules must now use ap_get_server_banner() or
ap_get_server_description() in place of ap_get_server_version().
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@440337 13f79535-47bb-0310-9956-ffa450edef68
to allow modules to review interdependent configuration directive
values and adjust them while messages can still be logged to the
console.
The open_logs phase is already used somewhat for this purpose by
certain MPMs (winnt, prefork, worker, and event) but only by forcing
their functions ahead of the core ap_open_logs() function, and
since this phase runs after the ap_signal_server function during startup,
it can not be used to generate messages on the console when restarting.
Add the check_config phase to mod_info and mod_example.
Handle relevant MPM directives during this phase and format messages
for both the console and the error log, as appropriate. Bounds and sanity
checks on the values of the MPM directives are handled in sequence in
this phase instead of in the various directive handling functions, since
those functions (e.g., set_max_clients()) may not be called at all if their
directives do not appear in the configuration files, and even if they
are called, there is no guarantee that this will occur in any particular
order.
Remove from the worker and event MPMs the code in the pre_config phase
that alters the configuration node tree by re-ordering ThreadsPerChild
ahead of MaxClients. This code is effective but insufficient; for
example, if ServerLimit follows MaxClients, the test against server_limit
in set_max_clients() is invalid. (In practice, this only results in
incorrect or absent warnings on the console, because server_limit is
set to its configured value when the main loop re-runs the configuration
process.)
Prevent ap_threads_per_child from exceeding thread_limit in the
winnt, worker, and event MPMs. This situation could occur if
ThreadsPerChild was not specified in the configuration files and
ThreadLimit was set to a value smaller than DEFAULT_THREADS_PER_CHILD,
because set_threads_per_child() would never be called and therefore
its bounds check against thread_limit would not be performed.
Remove from the winnt, prefork, worker, and event MPMs the
changed_limit_at_restart flag. Set the first_server_limit and
first_thread_limit values during the first execution of the check_config
function, and use them to detect changes to ServerLimit and ThreadLimit
across restarts and issue appropriately formatted warnings. Remove the
comments about the error log being a "bit bucket"; this was true when
the code was originally committed in r92530 but that was due to a bug
fixed in r92769.
Be consistent about setting all MPM configuration directive values in the
pre_config phase.
Rephrase and reformat the console and log file messages relating to
MPM configuration directives to be consistent across all MPMs. Use
briefer messages when logging to the error log than to the console.
Update miscellaneous stale comments and messages (e.g., reference to
daemons_min_free in worker and event MPMs, "prefork open_logs" in
winnt MPM, and StartServers in netware MPM).
The winnt, netware, beos, and mpmt_os2 MPMs should be tested by developers
with access to those platforms, especially the winnt MPM, which has
unique logic with respect to distinguishing between parent and child
processes during the configuration phases.
Update the English documentation for the worker MPM's ThreadsPerChild
directive, which no longer needs to precede other MPM directives in the
configuration files if it has a non-default value. The German (.de) and
Japanese (.ja) translations should be updated by developers fluent in
those languages.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@431460 13f79535-47bb-0310-9956-ffa450edef68
The return value is index to the signaled thread in
the creted_threads array.
We can not use WAIT_TIMEOUT as return value
because its value is defined as 258, thus limiting
the MaxThreads to that value that leads to the
assertion errors.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@428029 13f79535-47bb-0310-9956-ffa450edef68
returns WAIT_ABANDONED_NN instead presumed
WAIT_OBJECT_NN. This will correctly close the thread
handle without using invalid thread handle array index.
Spotted when large balancer timeout was set
and all the threads were busy waiting for the
connection:
[Wed Aug 02 14:29:58 2006] [crit] [Wed Aug 02 14:29:58 2006] file \\build-2.2.2\\server\\mpm\\winnt\\child.c, line 1120, assertion "(rv >= 0) && (rv < threads_created)" failed
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@428008 13f79535-47bb-0310-9956-ffa450edef68
sendfile_nonblocking being declared outside ifdefs even though the
function is defined and used only when APR_HAS_SENDFILE
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@425571 13f79535-47bb-0310-9956-ffa450edef68
