pooled connections if the client connection is an initial connection.
This avoids the "proxy: error reading status line from remote server"
error caused by the race condition that the backend server closed the
connection after the connection check on our side and before our data
reached the backend. Yes, this downgrades performance, especially with
HTTP/1.0 clients. Hence it is configurable and off by default.
PR: 37770
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@684351 13f79535-47bb-0310-9956-ffa450edef68
Ensure that the EOC bucket is inserted BEFORE an EOS bucket in bb as
some resource filters like mod_deflate pass everything up to the EOS
down the chain immediately and sent the remainder of the brigade later
(or even never). But in this case the ap_http_header_filter does not
get out of our way soon enough.
http_filters.c
Remove all data buckets that are in a brigade after an EOC bucket
was seen, as an EOC bucket tells us that no (further) resource
and protocol data should go out to the client. OTOH meta buckets
are still welcome as they might trigger needed actions down in
the chain (e.g. in network filters like SSL).
Remark 1: It is needed to dump ALL data buckets in the brigade
since an filter in between might have inserted data
buckets BEFORE the EOC bucket sent by the original
sender and we do NOT want this data to be sent.
Remark 2: Dumping all data buckets here does not necessarily mean
that no further data is send to the client as:
1. Network filters like SSL can still be triggered via
meta buckets to talk with the client e.g. for a
clean shutdown.
2. There could be still data that was buffered before
down in the chain that gets flushed by a FLUSH or an
EOS bucket.
PR: 37770
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@660726 13f79535-47bb-0310-9956-ffa450edef68
subrequests to support message bodies. Make sure that safety
checks within the core and within the proxy are not triggered
when kept_body is present. This makes it possible to embed
proxied POST requests within mod_include.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@654968 13f79535-47bb-0310-9956-ffa450edef68
we are a reverse proxy request shutdown the connection WITHOUT ANY response
to trigger a retry by the client if allowed (as for idempotent requests).
BUT currently we should not do this if the request is the first request on
a keepalive connection as browsers like seamonkey only display an empty page
in this case and do not do a retry.
Related to PR 37770
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@645813 13f79535-47bb-0310-9956-ffa450edef68
Basicly the persistence is created by keeping the conn_rec structure
created for our backend connection (whether http or https) in the connection
pool. This required to adjust scoreboard.c in a way that its functions can
properly deal with a NULL scoreboard handle by ignoring the call or returning
an error code.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@602542 13f79535-47bb-0310-9956-ffa450edef68
We'll need this option to fix PR#43711, and ap_send_interim_response
is fortunately too new an API to have made it into anything stable.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@588806 13f79535-47bb-0310-9956-ffa450edef68
PR 25947
RFC2616 tells us:
(1) If we haven't authenticated, we must pass the header on.
(2) If we have authenticated, we MAY pass it on.
I've made the latter case configurable by ENV(Proxy-Chain-Auth).
Also, Proxy-Authenticate is a response header, and doesn't belong
in a check of request headers.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@574021 13f79535-47bb-0310-9956-ffa450edef68
processing of error responses (4xx, 5xx) will be altered.
PR: 39245
This is based on a patch submitted by Bart van der Schans <schans hippo.nl>
and tweaked slightly by me based on discussions on dev@ since April 2006.
I think rpleum was the first to mention the 1xx issue.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@527969 13f79535-47bb-0310-9956-ffa450edef68
