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
from the connection pool twice. This causes this connection to be present
in the connection pool twice. Thus it may be used by different threads
at the same time which causes many troubles (segfaults in this case).
Furthermore implement a logic to prevent double releases to the connection
pool if they are triggered by buggy code and log an error message in this
case.
- mod_proxy_http.c: remove double calls to ap_proxy_http_cleanup
- proxy_util.c: Add logic to prevent double releases of a
connection to the connection pool.
PR: 38793
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@394088 13f79535-47bb-0310-9956-ffa450edef68
handle them correctly, because we recreate backend->connection for each
request and thus try to initialize an already existing SSL connection.
Noticed by: Joe Orton
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@379237 13f79535-47bb-0310-9956-ffa450edef68
backend servers. PR38602. [Ruediger Pluem, Jim Jagielski]
Also, document previous patch:
*) Correctly initialize mod_proxy workers, which use a
combination of local and shared datasets. Adjust logging
to better trace usage. PR38403. [Jim Jagielski]
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@378032 13f79535-47bb-0310-9956-ffa450edef68
