RE: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2
My bad.
Needs to be
RewriteRule ^/my_app/(.*) %{ENV:protocol}://1.2.3.4/my_app/$1 [P]
Regards
Rüdiger
From: Mike Rumph
Sent: Dienstag, 8. Oktober 2013 22:17
To: dev@httpd.apache.org
Subject: Re: [PATCH 55315] mod_proxy interpolation code broken by regression to
APR-util 1.5.2
Sorry.
I got carried away with the generic translation.
I was instead browsing to http://localhost:8080/my_app/
With the results indicated below.
Thanks,
Mike Rumph
On 10/8/2013 1:09 PM, Mike Rumph wrote:
I tried the configuration below with httpd trunk:
RewriteEngine On
RewriteCond %{HTTPS} =off
RewriteRule . - [E=protocol:http]
RewriteCond %{HTTPS} =on
RewriteRule . - [E=protocol:https]
RewriteRule ^/my_app/(.*) %{protocol}://1.2.3.4/my_app/$1 [P]
ProxyPassReverse /my_app/ http://1.2.3.4/my_app/
ProxyPassReverse /my_app/ https://1.2.3.4/my_app/
Then browsing to http://1.2.3.4/my_app/ gives me the following result:
Not Found
The requested URL /://1.2.3.4/my_app/ was not found on this server.
Any other suggestions?
Thanks,
Mike
On 9/17/2013 9:32 AM, Jim Jagielski wrote:
+1
On Sep 17, 2013, at 11:32 AM, Jeff Trawick
traw...@gmail.commailto:traw...@gmail.com wrote:
On Tue, Sep 17, 2013 at 11:30 AM, Plüm, Rüdiger, Vodafone Group
ruediger.pl...@vodafone.commailto:ruediger.pl...@vodafone.com wrote:
IMHO yes. But I am a mod_rewrite fan anyway :-).
not really a rewrite fan, but I think that's better than code
so IMO we should doc that interpolation isn't supported in the scheme, and
instead a solution like that should be used
Regards
Rüdiger
-Original Message-
From: Jim Jagielski [mailto:j...@jagunet.com]
Sent: Dienstag, 17. September 2013 17:26
To: dev@httpd.apache.orgmailto:dev@httpd.apache.org
Subject: Re: [PATCH 55315] mod_proxy interpolation code broken by
regression to APR-util 1.5.2
Doesn't that completely avoid/ignore the issue in the 1st place?
On Sep 17, 2013, at 11:08 AM, Plüm, Rüdiger, Vodafone Group
ruediger.pl...@vodafone.commailto:ruediger.pl...@vodafone.com wrote:
How about
RewriteEngine On
RewriteCond %{HTTPS} =off
RewriteRule . - [E=protocol:http]
RewriteCond %{HTTPS} =on
RewriteRule . - [E=protocol:https]
RewriteRule ^/my_app/(.*) %{protocol}://1.2.3.4/my_app/$1 [P]
ProxyPassReverse /my_app/ http://1.2.3.4/my_app/
ProxyPassReverse /my_app/ https://1.2.3.4/my_app/
?
Regards
Rüdiger
From: Jeff Trawick [mailto:traw...@gmail.com]
Sent: Dienstag, 17. September 2013 15:24
To: Apache HTTP Server Development List
Subject: Re: [PATCH 55315] mod_proxy interpolation code broken by
regression to APR-util 1.5.2
On Wed, Sep 4, 2013 at 5:12 PM, Mike Rumph
mike.ru...@oracle.commailto:mike.ru...@oracle.com
wrote:
Hello Jeff,
Thanks for your reply.
On 9/3/2013 6:58 AM, Jeff Trawick wrote:
Since the URL validation in apr_uri_parse() has been tightened in the
handling of the scheme portion of a URL,
I submitted a patch to httpd bug 55315 against the mod_proxy code in
httpd trunk to handle the special case
of interpolating a variable in the scheme portion of a URL.
- https://issues.apache.org/bugzilla/show_bug.cgi?id=55315
Do you know if it is practical to have the one magic path down to
ap_proxy_define_worker() munge the URI? I guess the problem is that
ap_proxy_define_worker() saves the parsed uri, and the caller (add_pass
or whatever it is) doesn't have access to that?
I take your point to be that the mod_proxy patch I submitted cannot be
applied to the branches, since it changes the API.
So I've submitted a new patch that is applied further up the stack in
add_pass() in mod_proxy.c.
That patch
(https://issues.apache.org/bugzilla/attachment.cgi?id=30799) is the one
I'm considering, as it is the one that could solve the issue for 2.2.x
(with a minor tweak) and 2.4.x (as-is), and I don't think the function
API issue is the major concern. Instead, carrying the interpolation
expression around in the worker scheme field separate from an
interpolation flag seems to be the overriding issue.
Dynamic determination of the scheme seems very useful and I don't know
of another way to implement the same requirement, which is well
illustrated by the now-broken config in the bug:
ProxyPassInterpolateEnv On
RewriteEngine On
RewriteCond %{HTTPS} =off
RewriteRule . - [E=protocol:http]
RewriteCond %{HTTPS} =on
RewriteRule . - [E=protocol:https]
ProxyPass /my_app/ ${protocol}://1.2.3.4/my_app/ interpolate
ProxyPassReverse /my_app/ ${protocol}://1.2.3.4/my_app/
interpolate
Any alternate ideas for configuring something like that?
Otherwise, any objections to patch 30799 (URL above)?
It is interesting that my research seems to indicate that mod_proxy
interpolation was actually the first to be introduced into the code.
I guess the order is this:
1. support
Re: svn commit: r1516930 - in /httpd/httpd/trunk: docs/manual/mod/mod_proxy.xml modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h modules/proxy/mod_proxy_ajp.c modules/proxy/mod_proxy_http.c modules
Committed revision 1530603.
thx again!
On Oct 8, 2013, at 4:24 PM, Yann Ylavic ylavic@gmail.com wrote:
Sure, here it is.
Please note 2 chances compared to the previous patch (pasted) :
- the slow path ap_request_has_body used last to compute do_100_continue,
- step Three-and-a-Half moved into step 3, with the associated comment
updated.
For the latter change, it avoids the systematic double-check (needlessly,
IMHO) when light ping is configured and the connection is reused.
Thank you for taking that into account.
On Tue, Oct 8, 2013 at 8:52 PM, Jim Jagielski j...@jagunet.com wrote:
OK, I gotcha now...
Do you have a patch file? tia!
On Oct 8, 2013, at 12:56 PM, Yann Ylavic ylavic@gmail.com wrote:
On Tue, Oct 8, 2013 at 6:26 PM, Jim Jagielski j...@jagunet.com wrote:
Does it matter whether or not it's a heavy ping or not?
It doesn't matter what sort of test was used, the socket is down.
Yes it is down, but for the ajp case for example, that determines the
return value GATEWAY_TIMEOUT vs INTERNAL_SERVER_ERROR, and according to the
comments, the former is when cping/cpong was used and that will not affect
the whole worker, does it make sense when the light ping (socket
health-check) only was done before forwarding?
For the ap_proxy_http_request error case, should mod_proxy retry a new
request when the heavy ping is off (light ping on)?
For ap_proxy_create_hdrbrgd and ap_proxy_process_response, the 100
continue things have nothing to do with light ping only, have they?
Regards.
On Oct 8, 2013, at 11:53 AM, Yann Ylavic ylavic@gmail.com wrote:
Hi,
Some code in trunk still only check for ping_timeout_set without
ping_timeout positive value to handle the heavy ping (CPING/Expect:
100-continue), see patch below.
Regards,
Yann.
Index: modules/proxy/mod_proxy_ajp.c
===
--- modules/proxy/mod_proxy_ajp.c(revision 1530243)
+++ modules/proxy/mod_proxy_ajp.c(working copy)
@@ -341,7 +341,8 @@ static int ap_proxy_ajp_request(apr_pool_t *p, req
* we assume it is a request that cause a back-end timeout,
* but doesn't affect the whole worker.
*/
-if (APR_STATUS_IS_TIMEUP(status)
conn-worker-s-ping_timeout_set) {
+if (APR_STATUS_IS_TIMEUP(status)
conn-worker-s-ping_timeout_set
+ conn-worker-s-ping_timeout = 0) {
return HTTP_GATEWAY_TIME_OUT;
}
@@ -661,7 +662,9 @@ static int ap_proxy_ajp_request(apr_pool_t *p, req
* we assume it is a request that cause a back-end timeout,
* but doesn't affect the whole worker.
*/
-if (APR_STATUS_IS_TIMEUP(status)
conn-worker-s-ping_timeout_set) {
+if (APR_STATUS_IS_TIMEUP(status)
+conn-worker-s-ping_timeout_set
+conn-worker-s-ping_timeout = 0) {
apr_table_set(r-notes, proxy_timedout, 1);
rv = HTTP_GATEWAY_TIME_OUT;
}
Index: modules/proxy/proxy_util.c
===
--- modules/proxy/proxy_util.c(revision 1530243)
+++ modules/proxy/proxy_util.c(working copy)
@@ -3073,6 +3073,7 @@ PROXY_DECLARE(int) ap_proxy_create_hdrbrgd(apr_poo
* We also make sure we won't be talking HTTP/1.0 as well.
*/
do_100_continue = (worker-s-ping_timeout_set
+(worker-s-ping_timeout = 0)
ap_request_has_body(r)
(PROXYREQ_REVERSE == r-proxyreq)
!(apr_table_get(r-subprocess_env,
force-proxy-request-1.0)));
Index: modules/proxy/mod_proxy_http.c
===
--- modules/proxy/mod_proxy_http.c(revision 1530243)
+++ modules/proxy/mod_proxy_http.c(working copy)
@@ -1241,6 +1241,7 @@ int ap_proxy_http_process_response(apr_pool_t * p,
dconf = ap_get_module_config(r-per_dir_config, proxy_module);
do_100_continue = (worker-s-ping_timeout_set
+(worker-s-ping_timeout = 0)
ap_request_has_body(r)
(PROXYREQ_REVERSE == r-proxyreq)
!(apr_table_get(r-subprocess_env,
force-proxy-request-1.0)));
@@ -1992,8 +1993,9 @@ static int proxy_http_handler(request_rec *r, prox
*/
if ((status = ap_proxy_http_request(p, r, backend, worker,
conf, uri, locurl,
server_portstr)) != OK) {
-if ((status == HTTP_SERVICE_UNAVAILABLE)
worker-s-ping_timeout_set
- worker-s-ping_timeout 0) {
+if ((status ==
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 09/10/2013 02:22, Trevor Perrin wrote: Hi Kaspar, Stephen, So I think where things stand is that the OpenSSL 1.0.2 branch is capable of handling ServerInfo on a per-algorithm basis, but it's not clear how to expose this through Apache. (My previous email was naive, I was thinking maybe Stephen was saying the current certificate / current key concept was already exposed through to Apache, but I don't think it is). Technically the current certificate concept doesn't need exposing at all. You just have to make sure you set all the relevant parameters *after* you set the certificate they apply to and *before* you set another one. So is there some way I could implement mod_ssl support for ServerInfo without a major rewrite of how mod_ssl handles certs and keys? (which some of the previous suggestions seemed to entail...) I can see two ways to do this. One is to add some code to Apache that just covers ServerInfo and is a directive at the same level as certificates (apologies, not sure what the actual term for that is). You then make sure you apply the value of that directive when you set the relevant certificate. The other is to enhance the SSL_CONF code in Apache so it can also store per-certificate parameters. The SSL_CONF currently works in Apache is to store all the SSL_CONF commands in an array during configuration and replay them when the SSL_CTX is set. That's OK for parameters that apply to the whole server (which reminds me support for client mode in Apache would be good too) but not for individual certificates. What you'd do to extend this is to have an array stored at the certificate level and replay it after the appropriate certificate is set. It's tempting to just add a directive but after some thought I think expanding Apache SSL_CONF handling is the way to go. This would add some future proofing so we don't have to go through this all again in future. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 02/10/2013 08:35, Kaspar Brand wrote: On 01.10.2013 12:15, Dr Stephen Henson wrote: That's just OpenSSL internals though. To handle ServerInfo properly in mod_ssl IMHO you would need a new directive as there's no support for per-certificate SSL_CONF commands: it wasn't intended to be used like that in its current form. This also runs against what IMHO is a long standing historical problem with the way mod_ssl handles certificates: it hard codes the algorithms used in the source. That means every new algorithm needs mod_ssl code changes to support: ECC for example. True. I guess it's a side effect of keeping private key pass phrases in the global SSLModConfigRec. From ssl_private.h: /* BIG FAT WARNING: SSLModConfigRec has unusual memory lifetime: it is * allocated out of the process pool and only a single such * structure is created and used for the lifetime of the process. [...] * This odd lifetime strategy is used so that encrypted private keys * can be decrypted once at startup and continue to be used across * subsequent server reloads where the interactive password prompt is * not possible. [...] * This should really be fixed using a smaller structure which only * stores that which is absolutely necessary (the private keys, maybe * the random seed), and have that structure be strictly ABI-versioned * for safety. Whether the latter is doable without breaking backward config compatibility (in particular for the SSLCertificate*File directives) needs further examination, I guess. I'd be interested in seeing what can be done to address this. One problem I noticed in the past is that the serialisation of keys in Apache is not algorithm independent: you can get around that by using PKCS#8 which is supported in all the versions of OpenSSL of interest. Well it works for software keys. For HSM keys there are some rather thorny issues which are trickier to handle. I don't think those are currently supported? Are you (or is anyone else) aware of any limitations on the OpenSSL side that prevent revision of the code to support arbitrary numbers of certificates in an algorithm independent way? There's one (relatively minor) one I can think of. If you set another certificate of the same type OpenSSL silently overwrites the old one. That means you can't currently catch configuration errors: e.g. trying to use two certificates of the same type. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
