git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1848047 13f79535-47bb-0310-9956-ffa450edef68

from the Include/IncludeOptional directives into a generic set of
functions ap_dir_nofnmatch() and ap_dir_fnmatch().


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1847430 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1847295 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1847234 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1847232 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1846651 13f79535-47bb-0310-9956-ffa450edef68

I have choosen "unlikely" because this bug has been around for ever ([1]) and the pool is only "cleared"; that is to say, the data is still valid, but the memory *could* be re-used.

[1]: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/dav/main/mod_dav.c?revision=85717&view=markup&sortby=date#l1610

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1846339 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1846310 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1846309 13f79535-47bb-0310-9956-ffa450edef68

* docs/manual/programs/htpasswd.xml: Document that bcrypt rounds are
capped at 17.

PR: 62078


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1846254 13f79535-47bb-0310-9956-ffa450edef68

PR: 33207


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1846253 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1846125 13f79535-47bb-0310-9956-ffa450edef68

     on HTTP/2 connections. Fixes PR 62654. [Stefan Eissing]



git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1846111 13f79535-47bb-0310-9956-ffa450edef68

     afterwards. Otherwise errors are reported when other SSL using modules
     are in play. Fixes PR 62880. [Michael Kaufmann]



git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1845768 13f79535-47bb-0310-9956-ffa450edef68

  Apache::Test is stale and needs updating.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1845441 13f79535-47bb-0310-9956-ffa450edef68

Actually *len can be > 0 here, at least without a change I'm working on but now
think should be discussed first probably. Anyway r1844928 alone is broken, just
rollback for now.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1845064 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844960 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844958 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844942 13f79535-47bb-0310-9956-ffa450edef68

No functional change, we never get there when *len > 0.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844928 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844889 13f79535-47bb-0310-9956-ffa450edef68

This needs the same bucket insertion code as in char_buffer_write(), so define
a new char_buffer_insert() helper.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844781 13f79535-47bb-0310-9956-ffa450edef68

This improves performances while still preventing morphing buckets bound to
r->pool from reaching connection filters.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844780 13f79535-47bb-0310-9956-ffa450edef68

Otherwise they are not considered by ap_filter_input_pending() and pipelining
is not detected (MPM event times out).


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844779 13f79535-47bb-0310-9956-ffa450edef68

Update doc accordingly.

Slightly tweak mod_speling doc

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844598 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844557 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844556 13f79535-47bb-0310-9956-ffa450edef68

statedir instead of runtimedir twice.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844484 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844421 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844420 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844403 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844402 13f79535-47bb-0310-9956-ffa450edef68

                 onsuccess vs always

In PR 62380 a user was confused why Header set always
was not overriding a header set by a HTTP backend managed
via mod_proxy_http. The difference between 'onsuccess'
and 'always' is really subtle, even if somebody is familiar
with r->headers_out and r->err_headers_out and the httpd's
internals.

As Stefan mentioned over email, the absence of a "normalized"
headers list in the response should be explained, so I tried to
do so in this commit.





git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844401 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844354 13f79535-47bb-0310-9956-ffa450edef68

Fix a cppcheck warning and a style issue.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844352 13f79535-47bb-0310-9956-ffa450edef68

  message.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844343 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844090 13f79535-47bb-0310-9956-ffa450edef68

  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.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844002 13f79535-47bb-0310-9956-ffa450edef68

See https://github.com/jfclere/JBCSP-17 for example...


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1844001 13f79535-47bb-0310-9956-ffa450edef68

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.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1843954 13f79535-47bb-0310-9956-ffa450edef68