问题描述
我的gwt / gae应用程序利用活动和地点。为了创建异步进程（例如重置密码或验证电子邮件地址的所有权），我使用一种模式，在该模式中可以将活动的状态标记并存储在数据存储区中，然后再检索并恢复。为了检索状态令牌，我有一个地方将扩展令牌标识作为参数，从数据存储中获取它，然后根据需要导航到适当的位置以恢复处理。这使我可以创建一个指向我的应用程序的特定状态的链接，可以通过电子邮件分发。例如：
My gwt / gae application utilizes activities and places. In order to create asynchronous processes (such as resetting a password or verifying ownership of an email address) I use a pattern where an activity's state can be tokenized and stored in the datastore, then retrieved and resumed later. In order to retrieve the state token I have a place which takes an augmented token id as an argument, fetches it from the datastore, then navigates to the appropriate place as necessary to resume to process. This enables me to create a link to a specific state of my application which can be distributed via email. for example:
http://mydomain.com/#signup:anJlbmZyb0BldGhvc2VkZ2UuY29tfDEzNzQxOTIxNjU3NjQ=
在这种情况下，上述链接将被发送到注册期间使用的电子邮件地址，并且应用程序将恢复由散列参数标识的注册活动。
In this case, the above link would be sent to the email addres used during signup and the application will resume the signup activity identified by the hash argument.
通过将以下代码添加到我的web.xml中，所有内容一直运行良好，直到最近我添加了SSL证书并为所有请求强制实施了https：
Everything has been working well until recently when I added an SSL cert and enforced https for all requests by adding the following code to my web.xml:
<security-constraint>
<web-resource-collection>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
这个约束强制https via（我相信）301重定向到443端口。 Chrome浏览器，火狐浏览器和IE浏览器....但Safari浏览器似乎放弃了重定向的url片段......我想你可以看到我的问题！如何防止Safari浏览器丢弃url碎片？
This constraint enforces https via (I believe) a 301 redirect to port 443. Works like a charm in Chrome, Firefox and IE.... however safari seems to drop the url fragment upon redirect... I think you can see my problem! How do I prevent safari from dropping the url fragment?!
经过艰辛的研究，我想我已经找到了根本原因，但我还没有找到一个好的解决方案。在w3c备忘录中提供了有关该问题的详细说明（1999）
After exhausting research, I think I have identified the root cause, but I have yet to find a good solution. A thorough description of the problem was provided in the w3c memo Handling of fragment identifiers in redirected URLs (1999)
基本上，http规范并不清楚3xx重定向期间处理url片段的情况; Safari浏览器选择在重定向时删除片段。查看以下Bugzilla错误：
Basically, http spec was unclear as to the handling of url fragments during 3xx redirects; and safari chose to drop the fragment when redirected. See the following bugzilla bug:
https://bugs.webkit.org/show_bug.cgi?id=24175
所需行为由w3c的通讯用户代理问题描述：
The desired behavior is described by w3c's commun user agent problems:
http://www.w3.org/TR/cuap#uri
因此，鉴于这一切，我认为这是一个safari（webkit）问题。我不明白为什么其他webkit浏览器不受影响？是否有已知的解决方法？
So in light of all this, I believe that this is a safari (webkit) issue. What I don't understand is why aren't other webkit browsers affected? Is there a known workaround?
推荐答案
只需提供一个重定向页面（200），在加载时刷新window.location并注入哈希片段。
Just serve a redirect page (200) that refreshes the window.location upon load and injects the hash fragment.
<!DOCTYPE html>
<meta charset="utf-8">
<html>
<body>
<script>
var hash = (location.href.split("#")[1] || null);
var pathField = "{{redirectUri}}";
if (hash) {
if (pathField.indexOf("#") == -1) {
pathField = pathField + "#" + hash;
}
}
window.location = pathField;
</script>
</body>
</html>
这样，它适用于每个浏览器（至少支持JavaScript的浏览器）。 {{redirectUri}}是您要重定向到的网址。如果它已经包含片段，则不会被覆盖。
That way, it works with every browser (at least browsers that support javascript). {{redirectUri}} is the URL you want to redirect to. If it contains a fragment already, it won't be overwritten.
这篇关于如何在重定向时保留Safari浏览器中的uri片段？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！