如何在apache HTTP Server中覆盖scheme和is_ssl for mod_proxy_ajp

时间:2016-01-06 13:09:03

标签: apache tomcat ajp mod-proxy-ajp

我们在负载均衡器后面运行Tomcat 7,它也可以作为SSL终结器和Apache HTTP Server 2.4。 Apache通过mod_proxy_ajp连接到Tomcat。

对于应用程序,重要的是Tomcat知道请求是通过HTTPS进入的,因此是安全的。例如, this article建议,通常使用属性secure="true"和可能scheme="https" proxyPort="443"在Tomcat的Connector上配置它。虽然这很有效,但由于我们也将HTTP用于某些目的,因此不方便,因此我们需要为此设置两个Tomcat连接器。它有一种气味,因为这样我们基本上告诉Tomcat覆盖它从Apache HTTP Server获取的错误信息,该请求是HTTPS而不是HTTP,而不是告诉Apache它应该发送关于协议的正确信息和安全状态。

所以我的问题是:在某种程度上可以配置Apache HTTP Server本身,它通过AJP协议传递正确的信息:请求是通过HTTPS接收的并且是安全的吗?问题是它不知道它是HTTPS,因为它之前有一个SSL终结符,并且请求通过HTTP到达,就其而言。我能以某种方式告诉Apache它实际上是HTTPS吗?

2 个答案:

答案 0 :(得分:0)

我一直认为AJP会自动传输这些信息 - 但我不是在使用mod_proxy_ajp,而是使用mod_jk。这是我更喜欢AJP over HTTP(和代理)的原因之一。

可能值得更改模块/连接

答案 1 :(得分:0)

Apache HTTP服务器中的虚拟主机中的部分解决方案似乎是to set the protocol on a ServerName directive

use std::error::Error;
use std::fs::File;
use std::io::prelude::*;
use std::path::Path;

fn main() {
    // Create a path to the desired file
    let path = Path::new("src/bench.html");
    let display = path.display();

    // Open the path in read-only mode, returns `io::Result<File>`
    let mut file = match File::open(&path) {
        // The `description` method of `io::Error` returns a string that
        // describes the error
        Err(why) => panic!("couldn't open {}: {}", display,
                                                   Error::description(&why)),
        Ok(file) => file,
    };

    // Read the file contents into a string, returns `io::Result<usize>`
    let mut s     = String::new();

    match file.read_to_string(&mut s) {
        Err(why) => panic!("couldn't read {}: {}", display,
                                                   Error::description(&why)),
        Ok(_) => {
            for x in 1..100 {
                for token in s.chars() {
                    match token {
                        _ => {
                            // noop
                        }
                    }
                }
            }
            println!("done!");
        }
    }
}

这样,重定向中的任何Location:头似乎都被重写为Apache中的https,但是Tomcat仍然通过AJP传递了错误的信息。