from the origin server
apr_date_checkmask() already verified the expected text and digit
positions; all that is needed is to cheaply find which digits
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@999694 13f79535-47bb-0310-9956-ffa450edef68
canon function and use that for the 100-Continue OK
check.
Should likely also start using this in the various
other places we do this "have body" check thruout
the codebase...
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@986699 13f79535-47bb-0310-9956-ffa450edef68
be more safe on different platforms.
Note: This commit has an additional, platform-independent change to
mark the back-end connection for closing ("backend->close = 1;").
That code is not required to resolve CVE-2010-2068 on any platform.
PR: 49417
Addresses CVE-2010-2068
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@953418 13f79535-47bb-0310-9956-ffa450edef68
from a reverse proxied URL, that the subrequest respects the status
of the original request. This brings the behaviour of proxy_handler
in line with default_handler. PR 47106.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@909899 13f79535-47bb-0310-9956-ffa450edef68
* modules/proxy/mod_proxy_http.c (stream_reqbody_cl): Specify the base
passed to apr_strtoff, and validate the Content-Length in the same
way the HTTP_IN filter does. If the number of bytes streamed
exceeds the expected body length, bail out of the loop.
Thanks to: Toadie <toadie643 gmail.com> for reporting and diagnosis of
this issue.
Submitted by: niq, jorton
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@790587 13f79535-47bb-0310-9956-ffa450edef68
stricter checking of remote server certificates.
(docs/manual/mod/mod_ssl.xml)
Documentation of SSLProxyCheckPeerExpire and SSLProxyCheckPeerCN.
(modules/proxy/mod_proxy_http.c)
Set the hostname of the request URL as note on the connection.
(modules/ssl/ssl_private.h)
Add proxy_ssl_check_peer_expire and proxy_ssl_check_peer_cn fields to
the SSLSrvConfigRec.
(modules/ssl/ssl_engine_config.c)
Directives stuff for SSLProxyCheckPeerExpire and SSLProxyCheckPeerCN.
(modules/ssl/ssl_engine_io.c)
Check whether the remote servers certificate is expired / if there is a
mismatch between the requested hostanme and the remote server certificates
CN field.
Be able to parse ASN1 times.
(modules/ssl/mod_ssl.c)
Directives stuff for SSLProxyCheckPeerExpire and SSLProxyCheckPeerCN.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@760866 13f79535-47bb-0310-9956-ffa450edef68
backend connection bucket allocator and front end connection bucket allocator.
Instead copy the buckets from the backend over to ones that have been created
using the front end bucket allocator. For metabucket this is done by recreating
them, for data buckets this is done by reading them and putting the read data
in a transient bucket.
PR: 45792
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@712375 13f79535-47bb-0310-9956-ffa450edef68
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
