On some platforms (e.g. OpenBSD) zlib's input/output counters are off_t
instead of ulong, which resuls in format-string warnings from some
compilers (e.g. clang). Work around this by upcasting to uint64_t.
Discussed on dev@ with ylavic and wrowe


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

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

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

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

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

     have been fixed. [Michael Kaufmann, Stefan Eissing]



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

In ap_resolve_env(), the string returned from getenv() should be copied since
the returned string may be statically allocated.

This fixes an issue where the value for the last env var is substituted for all
env vars in a directive containing multiple env vars.


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

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