JBoss 4.2.3、Apache mod_jk 和硬體負載平衡器的 SSL 重定向問題
我們目前在網路設置方面遇到了一些問題，我們到目前為止還沒有使用過，我希望獲得更多關於如何解決這個問題的意見。
我們一個客戶的網路在不同的伺服器上使用 4 個JBoss實例，它們都執行相同版本的軟體。它們共享一個公共數據庫並根據需要執行。該軟體正在執行並可以使用。我們不複製會話——每個 JBoss 都管理自己的會話池。
4 個 JBoss 實例被分成 2 個不同的段，每個段有 2 個 JBoss。這些段中的每一個都使用 2 個不同的 Apache Web 伺服器進行路由，使用mod_jk進行簡單的負載平衡。使用的連接器是JBoss 和 Apache 伺服器之間的AJP 。
兩台 Apache Web 伺服器都連接到一個硬體負載平衡器/路由器（我們的客戶目前還不是很清楚），它將內部請求（Intranet）路由到一個Web 伺服器，將外部請求（Internet）路由到另一個 Web 伺服器。所以我們有一個用於內部使用者的部分，另一個用於外部使用者。
客戶端通過他們的瀏覽器使用SSL加密的HTTPs連接——它是一個 Web 應用程序。SSL 加密由硬體負載平衡器終止。硬體負載平衡器和 2 個 Web 伺服器之間的通道是 HTTP（不再使用 SSL）。
問題：
在行尾，JBoss 不知道任何 SSL / HTTPs 通信，因此使用完整的http://地址而不是https://呈現一些****302 重定向。因此，另一端的客戶端瀏覽器從 https://（它最初用於連接到 Web 應用程序）切換到 http://（在來自 JBoss 的 302 重定向的情況下）。
我們的解決方案：
我們提供了兩種解決方案。一個是最後一端的簡單重寫規則 - 硬體負載平衡器 - 將所有 http:// 流量重寫為 https://。這將起作用並保持客戶端連接，但它被我們的客戶拒絕，因為它不尋常並且無法解決最初的問題。
另一種解決方案是將 SSL 加密擴展到 Web 伺服器，這將能夠通過 AJP 將安全標誌信號發送給 JBoss，而 JBoss 將接收並正確重定向。由於內部安全問題和準則，此解決方案被拒絕。
還有什麼？
所以我們目前陷入困境，戰線變硬。我們的 2 個解決方案有其他替代方案嗎？
另一種選擇應該是在 Apache 中使用 mod_headers 來修改 Location 響應頭：
Header edit Location ^http:(.*)$ https:$1
假設他們需要同時處理 http 和 https 流量，您可以嘗試另外提出以下建議之一：-
1）他們可以為來自負載均衡器的來自 https 的請求添加一個特定的標頭，以便 jboss 實例知道它最初是一個 https 請求。
2）您可以建議將 https 請求發送到 apache 中的不同埠（例如 8080 甚至 443，但未加密），以便 apache 知道它們來自 https。