Checkout Tools
  • last updated 5 hours ago
Constraints: committers
Constraints: files
Constraints: dates

Changeset 1844037 is being indexed.

* Vote and promote
Can confirm this resolves H2 test failure issues introduced w/ OpenSSL 1.1.1
Typo in proposed revision number.

Thanks to Daniel for the heads up.

Died on the vine
* Correctly merge configurations that have client certificates set

by SSLProxyMachineCertificate{File|Path}.

The certificates and keys loaded during configuration time got lost during

runtime if e.g. SSLProxyMachineCertificate{File|Path} was set on virtual host

level and there was an SSL directive at directory level, e.g. SSLRequire.

This fixes a regression likely introduced in r1740928.

And a way to custom modules to guess and extract ssl variable.

See for example...


SSL_read() doesn't distinguish between return value 0 and <0,

at least not for OpenSSL 1.1.1. This is documented in the man

page for SSL_read and let to h2 failures when using OpenSSL 1.1.1.

When no data could be read, our code returned EAGAIN up until

OpenSSL 1.1.0, but APR_EOF for OpenSSL 1.1.1.

Now instead check SSL_get_error() also when SSL_read() returns 0.

To keep changes small, this change should not influence behavior,

when (rc=SSL_read()):

- rc < 0

- rc == 0 && *len > 0

- rc == 0 &&

(APR_STATUS_IS_EAGAIN(inctx->rc) || APR_STATUS_IS_EINTR(inctx->rc) &&

inctx->block == APR_NONBLOCK_READ

Behavior changes if

- rc == 0 &&

!(APR_STATUS_IS_EAGAIN(inctx->rc) || APR_STATUS_IS_EINTR(inctx->rc) &&

!*len > 0

Instead of APR_EOF:

- same behavior as rc < 0 for SSL_ERROR_WANT_READ

- same behavior as rc < 0 for SSL_ERROR_SYSCALL && APR_STATUS_IS_EAGAIN(inctx->rc)

Another change is that rc == 0 && ssl_err == SSL_ERROR_ZERO_RETURN

also results in APR_EOF.

* Ensure that aborted connections are logged as such.

Set c->aborted before apr_brigade_cleanup to have the correct status

when logging the request as apr_brigade_cleanup triggers the logging

of the request if it contains an EOR bucket.

PR: 62823

Submitted by: Arnaud Grandville <>

Reviewed by:rpluem

backport votes

Revert r1832567, r1843476, r1843478

Restore jorton's detection from r1831398, and portably redirect stderr

to capture and evaluate the available command list,

from either stdout (1.1.0 and later) or stderr (1.0.2 and prior).

md_acme_drive.c: remove unused variable

Compiling in maintainer mode leads to a failure

due to challenges_configured initialized but

not used. Removing it seems harmless, Stefan

please let me know if this is not the case.

XML update.

fr doc rebuild.

XML update.

fr doc rebuild.

XML updates.

first step in trying to make this test stop try to build curl. I have curl. The right one. With HTTP2 support. So why do we need to rebuild? Who knows. But now I need to figure out what to do about clients/Makefile*

propose "at maxrequestworkers" patch

On the trunk:

mod_md: eliminating compiler warnings re signedness and unused. Adding a APLOG_WARNING

when the only available ACME challenge is "tls-sni-01" since Let's Encrypt will

disable that completely beginning of 2019.

Adjusting version check to lowest httpd version that may support TLSv1.3

* This is addressed now
mpm_event: avoid AH00484 with idle threads

mpm_event: Stop issuing AH00484 "server reached MaxRequestWorkers..." when

there are still idle threads available. When there are less idle threads than

MinSpareThreads, issue new one-time message AH10159. Matches worker MPM.

Post 2.4.36 tag updates
Tag HEAD of 2.4.x as 2.4.36
Get ready to tag httpd 2.4.36
Better method... just check return status

Use this cli command

Note release
Merge r1843242 from trunk:

mod_brotli, mod_deflate: Restore the separate handling of 304 Not Modified

responses allowing these modules to properly set or fix-up the response

headers such as Vary or ETag.

This change follows up on r1837056 that disabled that special handling and

thus resulted in a potential violation of RFC7232, 4.1:

The server generating a 304 response MUST generate any of the following

header fields that would have been sent in a 200 (OK) response to the

same request: Cache-Control, Content-Location, Date, ETag, Expires,

and Vary.)


Submitted by: kotkov

Reviewed by: kotkov, ylavic, jim