When the backend responds with a non-interim response to a 100-continue,
mod_proxy_http won't read the client's body, so make sure "Connection: close"
ends up being added to the response if nobody reads that body later.


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

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

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

split up the two arguments into their own paragraphs
try to reinforce that the 2nd arg has to match the response
hedaer, and what the first one is used for.



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

When mod_proxy_http handles end-to-end "100 continue", it can't let
ap_http_filter() send its own interim response whenever the body is read.

So save/restore r->expecting_100 before/after handling the request, and use
req->expecting_100 internally (including to restore r->expecting appropriately).

While at it, add comments and debug logs about 100 continue handling, and
fill in missing APLOGNO()s from r1836588.


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

xform


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

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

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

  function at the same time. So rename ap_proxy_balancer_get_best_worker to
  proxy_balancer_get_best_worker and make it static which is then used as an
  optional function and recreate ap_proxy_balancer_get_best_worker as an
  exported thin wrapper of proxy_balancer_get_best_worker.


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

Handle end-to-end 100-continue, according to RFC 7231, such that the client
request body is not read/forwarded (according to its "Expect:" header) until
the backend wants to receive it (with interim 100 continue response), or never
forwarded if the backend provides a (non-interim) response and doesn't need
the client body at all.

This is achieved by filling the header_brigade in ap_proxy_http_prefetch()
and letting ap_proxy_http_request() determine whether it should forward that
brigade only (with the "Expect: 100-continue" specified by the client or added
according to "ping=" configuration), or forward the whole body for the usual
case (as before).

When 100-continue expectation is in place, the body is actually forwarded by
ap_proxy_http_process_response() when/if a "100 continue" response is sent by
the backend, otherwise the body is discarded; a future enhancement could make
so that in a balancer configuration, the body could be forwarded to another
balancer member depending on the status/error from the backend.

So stream_reqbody_cl() and stream_reqbody_chunked() functions are adapted to be
called by either ap_proxy_http_request() or ap_proxy_http_process_response(),
while spool_reqbody_cl() still spools the body in ap_proxy_http_prefetch() thus
before the backend is connected/reused to avoid inactivity on the connection
for the prefetch time (the prefetched body is also forwarded according to the
100-continue expectation, though).

Also, since the brigades and other runtime objects now need to be shared by the
ap_proxy_http_*() functions chain, a proxy_http_req_t struct/context is created
from the start and passed to them as (the single) argument. This is also a good
candidate for a future async baton, if we wanted to let the MPM event wait for
connection data for us at any stage and be called back ;)

Finally, ap_send_interim_response() is modified to correcly handle 100 continue
responses once, and take care of clearing r->expecting_100 only for them.

PR 60330.



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

  ENGINE support.

PR: 62563


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

  location in Fedora layout.


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

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

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

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

* Always retrieve conditional function. static variable might contain garbage if module was reloaded in a static build.

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

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

  modules and mod_proxy by providing mod_proxy's ap_proxy_balancer_get_best_worker
  as an optional function.

PR: 62557


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

They were superseded by ap_filter_should_yield() and ap_run_in/output_pending()
in r1706669 and had poor semantics since then (we can't maintain pending
semantics both by filter and for the whole connection).

Register ap_filter_input_pending() as the default input_pending hook (which
seems to have been forgotten in the first place).

On the MPM event side, we don't need to flush pending output data when the
connection has just been processed, ap_filter_should_yield() is lightweight and
enough to determine whether we should really enter write completion state or go
straight to reading. ap_run_output_pending() is used only when write completion
is in place and needs to be completed before more processing.


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

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

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

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

mod_proxy_hcheck was missing the merge of SSLProxy* directives defined by
balancer with the ones of the VirtualHost.

Since ap_proxy_connection_create_ex() needs a merged r->per_dir_config to apply
the correct SSL configuration, let's split create_request_rec() in two:
- create_request_rec() to only initialize the non-connection fields and merge
  balancer->section_config into r->per_dir_config,
- set_request_connection() to associate the connection with the request once
  it's been created from the merged configuration of the minimal request.

The issue was reported on the users@ mailing list:
https://lists.apache.org/thread.html/895cf250104b081b789101b1086b71a26d9c337db7123c5a552b7c69@%3Cusers.httpd.apache.org%3E


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

As Eric noted, this is safer w.r.t. third party buckets which could be
uncought by the previous backlist and get out of memory limits.


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

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

Since ap_filter_output_pending() is looping on the relevant filters already,
we don't need to use ap_filter_should_yield() to check upstream filters.


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

Straightforward for ap_filter_input_pending() since c->data_in_input_filter is
always checked wherever ap_run_input_pending(c) is.

For ap_filter_input_pending(), it allows to set c->data_in_output_filter in
ap_process_request_after_handler() to avoid an useless flush from mpm_event.


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

The core output filter used to determine first if it needed to block before
trying to send its data (including set aside ones), and if so it did call
send_brigade_blocking().

This can be avoided by making send_brigade_nonblocking() send as much data as
possible (nonblocking), and only if data remain check whether they should be
flushed (blocking), according to the same ap_filter_reinstate_brigade()
heuristics but afterward.

This allows both to simplify the code (axe send_brigade_blocking and some
duplicated logic) and optimize sends since send_brigade_nonblocking() is now
given all the buckets so it can make use of scatter/gather (iovec) or NOPUSH
option with the whole picture.

When sendfile is available and/or with fine tuning of FlushMaxThreshold (and
ReadBufferSize) from r1836032, one can now take advantage of modern network
speeds and bandwidth.

This commit also adds some APLOG_TRACE6 messages for outputed bytes (including
at mod_ssl level since splitting happens there when it's active).


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

Submitted by: Arkadiusz Miskiewicz <arekm maven.pl>


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

 * using the, hopefully correct, ever elusive libressl version numbering check for the new openssl API calls, fixes PR 62548.


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

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

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

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

ReadBufferSize allows to configure the size of read buffers, for now it's
mainly used for file buckets reads (apr_bucket_file_set_buf_size), but it could
be used to replace AP_IOBUFSIZE in multiple places.

FlushMaxThreshold and FlushMaxPipelined allow to configure the hardcoded
THRESHOLD_MAX_BUFFER and MAX_REQUESTS_IN_PIPELINE from "util_filter.c".
The former sets the maximum size above which pending data are forcibly flushed
to the network (blocking eventually), and the latter sets the number of
pipelined/pending responses above which they are flushed regardless of whether
a pipelined request is immediately available (zero disables pipelining).

Larger ReadBufferSize and FlushMaxThreshold can trade memory consumption for
performances with the capacity of today's networks.


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

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

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

Since it's internal util_filter use, we shouldn't expose it in conn_rec and
can replace it with a pooled brigade provided by ap_reuse_brigade_from_pool().


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

Current RETRIEVE_BRIGADE_FROM_POOL macro from "http_request.c" is turned into
a helper and used in ap_request_core_filter().

We will need it in a subsequent commit in "util_filter.c" too.


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

Register pending_filter_cleanup() as a normal cleanup (not pre_cleanup) so
that the pending filters are still there on pool cleanup, and f->bb is set
to NULL where needed.

Then is_pending_filter() check is moved where relevant.


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

(probably more about correctness than a real issue since systems are
unlikely to implement more than one/their method...).


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