Grails 重定向 - 为什么它总是绝对的？答案

【问题标题】：Grails redirect - why is it always absolute?Grails 重定向 - 为什么它总是绝对的？
【发布时间】：2011-07-11 08:13:42
【问题描述】：

我有两个 Jetty AppServer 在 Apache 2.2 反向代理后面运行 Grails Web 应用程序。 SSL 终止由 apache 完成，后者将 HTTP 传递给 Jetty AppServer。

当 Grails Web 应用程序像这样进行重定向时

redirect(action:'index')

最终用户收到带有完整 URL 的 HTTP 302 重定向请求，该 URL 使用的是 http:// 协议，而不是 https://：

HTTP/1.1 302 Found
Date: Tue, 08 Mar 2011 17:50:46 GMT
Server: Jetty(6.1.17)
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Location: http://hostname.domain/web/?lang=en

这很烦人，因为所有 HTTP 请求都会被代理捕获并重定向到 HTTPS 请求。所以这是不必要的往返。

我看到了两种解决方案：

Apache 的 mod_proxy 可以在将响应传递给用户之前将该 Location-header 重写为 https://。（可以吗？）
Grails 在重定向时不能使用绝对 URL：Location: /web/?lang=en

我认为第一个选项有点愚蠢，对吧？

您知道如何让 grails 发送非绝对重定向标头（理想情况下无需切换每个重定向以使用 uri:）吗？

编辑：目前我有一个解决方法，方法是修改响应标头（a2enmod headers，然后在<Location> 中添加Header edit Location ^http://(.*)$ https://$1）。灵感来自this serverfault post。我仍然想知道为什么这首先是必要的。

【问题讨论】：

标签： grails redirect https reverse-proxy

【解决方案1】：

302 redirects are required by the HTTP 1.1 RFC to be absolute，不是相对位置。即使它在某些浏览器中有效，但它们超出了规范，我敢肯定，如果您使用相对 url，某些实现将无法正常工作。

您看到此问题的原因是 SSL 终止发生在 apache 上，而 apache 正在向 Jetty 发出普通 HTTP 请求。所以 Jetty 收到一个普通的非 HTTPS 请求，因此它不知道发送 HTTPS 响应，而不是常规的 HTTP 响应。如果您在 Jetty 中进行 SSL 终止，则不会有问题（但 Jetty 在 SSL 终止方面并不是那么出色）。

我们已经在我们的应用程序（apache/HA Proxy->Tomcat）中处理了这个问题，方法是使用一个对响应协议进行硬编码的每个环境配置值（无论如何我们都需要弄乱 url，因为它是一个多租户系统许多潜在的主机名进来了，说来话长... :)，但是您使用 apache 的解决方案也可以。

【讨论】：

正确，尽管 FWIW，我还没有看到任何浏览器不支持相对 URL。我们试图在 IE7 Beta 1 中停止并在第二天恢复了该更改。 :-)

【解决方案2】：

这个问题现在差不多 10 年了。从那时起，该规范已在RFC 7231, section 7.1.2 中更新。现在允许 Location 标头中的相对引用：

当 [Location] 具有相对引用的形式 ([RFC3986], Section 4.2)，最终值是通过根据有效请求 URI 解析来计算的 ([RFC3986], Section 5)。

Grails 支持这种类型的重定向，但您必须在重定向时应用额外的 absolute: false 参数：

redirect action: 'index', absolute: false

注意：在撰写本文时，此功能（尚）不支持 servlet 上下文路径，请参阅 grails-core issue #11673

【讨论】：