Let's call stream_reqbody() for all rb_methods, no RB_SPOOL_CL special case.
This both simplifies code and allows to keep EOS into the input_brigade until
it's sent, and thus detect whether we already fetched the whole body if/when
proxy_http_handler() re-enters for different balancer members.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1869222 13f79535-47bb-0310-9956-ffa450edef68
Since r1656259 (or r1656259 in 2.4.41) and the move of prefetch before connect,
the balancer fallback case where proxy_http_handler() is re-entered with the
next balancer member broke.
We need to save the body (partially) prefetched the first time and reuse it on
successive calls, otherwise we might forward partial or empty body.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1869216 13f79535-47bb-0310-9956-ffa450edef68
The HTTP_IN filter handles "100 Continue" the first time it's called only,
and in spool_reqbody_cl() we have already tried to prefetch the body, so
it's too late.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1868652 13f79535-47bb-0310-9956-ffa450edef68
As suggested by Ruediger, let the HTTP_IN filter handle the 100 continue from
spool_reqbody_cl().
Also, according to rfc7231#section-5.1.1, we don't need the interim response
if we "already received some or all of the message body", which is now also
taken into account.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1868625 13f79535-47bb-0310-9956-ffa450edef68
Send "100 Continue", if needed, before fetching/blocking on the request body in
spool_reqbody_cl(), otherwise mod_proxy and the client can wait for each other,
leading to a request timeout (408).
While at it, make so that ap_send_interim_response() uses the default status
line if none is set in r->status_line.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1868576 13f79535-47bb-0310-9956-ffa450edef68
configuration and other proxy SSL configurations
broken inside <Proxy> context.
PR 63430
Triggered by r1855646+r1855748.
Patch from rpluem (proxy) and ylavic (ssl).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1859371 13f79535-47bb-0310-9956-ffa450edef68
Since stream_reqbody_cl() and stream_reqbody_chunked}() now have the same
structure, join them into a single stream_reqbody() function which is passed
the rb_method to handle only CL vs chunked cases differently.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853953 13f79535-47bb-0310-9956-ffa450edef68
Since the forwarding of 100-continue (end to end) in r1836588, we depended on
reading all of the requested HUGE_STRING_LEN bytes to avoid the flushes, but
this is a bit fragile.
This commit introduces the new stream_reqbody_read() function which will try a
nonblocking read first and, if it fails with EAGAIN, will flush on the backend
side before blocking for the next client side read.
We can then use it in stream_reqbody_{chunked,cl}() to flush client forwarded
data only when necessary. This both allows "optimal" flushing and simplifies
code (note that spool_reqbody_cl() also makes use of the new function but not
its nonblocking/flush functionality, thus only for consistency with the two
others, simplification and common error handling).
Also, since proxy_http_req_t::flushall/subprocess_env::proxy-flushall are now
meaningless (and unused) on the backend side, they are renamed respectively to
prefetch_nonblocking/proxy-prefetch-nonblocking, and solely determine whether
to prefetch in nonblocking mode or not. These flags were trunk only and may
not be really useful if we decided to prefetch in nonblocking mode in any case,
but for 2.4.x the opt-in looks wise.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853407 13f79535-47bb-0310-9956-ffa450edef68
Provide AP_STATUS_IS_HEADER_ONLY() helper/macro to check for 204 or 304 and
use it where some special treatment is needed when no body is expected.
Some of those places handled 204 only.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1837056 13f79535-47bb-0310-9956-ffa450edef68
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.
The right thing to do at mod_proxy level, rather then forcing AP_CONN_CLOSE,
is to restore r->expecting_100 so that further processing (like error_override
or trying on the next balancer member) can still work.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1836716 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
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
Export [ap_]check_pipeline() and use it also for ap_proxy_check_connection(),
so that all the necessary checks on the connection are done before reusing it.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1756186 13f79535-47bb-0310-9956-ffa450edef68
takes place, the response it to be handled by ErrorDocument is this case.
Also it useless to take care of pre-read data since the body is discarded in
this case.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1754974 13f79535-47bb-0310-9956-ffa450edef68
Avoid double checking the connection in ap_proxy_connect_backend() when
ap_proxy_check_backend() says it is up and good to go.
This can be done by moving the PROXY_WORKER_IS_USABLE() check in
ap_proxy_check_backend(), since it is called by ap_proxy_connect_backend(),
and not calling the latter if the former succeeded (for the modules using it).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1750474 13f79535-47bb-0310-9956-ffa450edef68
before the request is sent. PR 57832.
ap_proxy_check_backend() can be used before ap_proxy_connect_backend() to try
to read available data (including from the filters), and is called by
ap_proxy_connect_backend() to check the socket state only (as before, still
relevant after ap_proxy_check_backend() due to filter data which may not have
triggered a real socket operation).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1750392 13f79535-47bb-0310-9956-ffa450edef68
This used to check for the backend connection readability only (instead of
the full ping/100-continue round-trip), but the case is already handled by
ap_proxy_connect_backend() which is always called.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1729507 13f79535-47bb-0310-9956-ffa450edef68
