IE 不遵循重定向，给出“Internet Explorer 无法显示网页”
我有一个包含几个字段的表单。当您提交表单时，服务器会通过重定向 (HTTP 302) 进行响应。
提交表单时，如果存在 字段，IE 不会遵循重定向，而是给出错误：“Internet Explorer 无法显示网页”。
如果没有 字段，那么它确实会按预期遵循重定向。
两种情况下的 HTTP 302 响应完全相同，仅响应的时间戳不同。
我在 IE8 和 IE9 中遇到过这种情况。 （我没有尝试过较低版本）。 Firefox、Chrome、Opera 和 Safari 均按预期遵循重定向。
注意：
- 表单具有属性
enctype="multipart/form-data"。 - 这是通过 SSL 进行的。
- 重定向不会重定向到与表单 POST 到或托管的 URL 不同的协议、主机或端口。
- 当我使用 Fiddler2 检查 HTTP 流量时，问题消失并且 IE 正常运行。
I have a form with a few fields. When you submit the form, the server responds with a redirect (HTTP 302).
When the form is submitted, if there is an <input type=file> field, IE doesn't follow the redirect, but instead gives an error: "Internet Explorer cannot display the webpage".
If there is no <input type=file> field, then it does follow the redirect as expected.
The HTTP 302 Response is exactly the same in both cases, differing only by the timestamp of the response.
I'm experiencing this in IE8 and IE9. (I haven't tried lower versions). Firefox, Chrome, Opera and Safari all follow the redirect as expected.
Notes:
- The form has the attribute
enctype="multipart/form-data". - This is happening over SSL
- The redirect is not to a different protocol, host, or port than the URL the form POSTs to or is hosted on.
- When I inspect HTTP traffic with Fiddler2, the issue disappears and IE behaves.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这个问题已经有3年历史了，但我最近自己也遇到了这个问题，但在任何地方都没有找到正确的答案。此处标记为已接受的答案并没有真正回答任何问题。
对我来说重要的是在 302 响应中添加以下标头：
我正在重定向到具有完整 URL 的另一个站点，并且看起来 IE 正在尝试通过在同一 TCP 流上发送后续请求而不重新打开它来优化连接，但不够聪明，无法在标头中没有明确的“连接”指令的情况下找出该站点是不同的。
至少在IE10和IE11中会出现这种情况，其他浏览器都没有这个问题。
The question is 3 years old, but I recently ran into this problem myself and didn't find the correct answer anywhere. The answer marked as accepted here doesn't really answer anything.
What made a difference for me was adding the following header to the 302 response:
I was redirecting to another site with full URL, and it looks like IE is trying to optimize connections by sending subsequent requests over the same TCP stream without re-opening it, but is not smart enough to figure out that the site is different without explicit "Connection" instruction in the header.
This happens in at least IE10 and IE11, and none of the other browsers has this problem.
您的重定向是部分 URL 还是完整 URL（带有主机、协议等）？我在 PHP 中见过很多例子，其中 302 重定向没有完整的 http://server.dom/path/to其中的 /file 将被 IE 忽略或破坏。在 Rails 中，这可能是路由器中 foo_path 和 foo_url 之间的区别。
Is your redirect to a partial URL or a complete URL (with host, protocol, etc.)? I have seen plenty of examples in PHP where a redirect with 302 that does not have a complete http://server.dom/path/to/file in it will be ignored or mangled by IE. In Rails, this can be the difference between foo_path and foo_url in the router.
只是为了给有同样问题的人补充一下：
IE 似乎对 header 命令的形成方式非常严格。我的应用程序正在努力解决：
或
但当命令修改为： 时开始工作：
Just to add to this for anyone having the same problem:
IE seems quite strict about how the header command is formed. My application was struggling with:
or
But started working when the command was amended to:
对于遇到此问题的人来说，另一个提示是：
在我的情况下，某些 IE11 安装无法正确重定向，而其他安装则可以（甚至是相同版本的 IE）。
当它不起作用时，会发生的情况是 IE 无法检测到重定向页面的结尾和下一页的开头。
这在浏览器中表现为重定向页面末尾的一段 HTML 代码，后面紧跟着需要加载的实际页面的内容。
如果启用了压缩，我们将看到重定向页面的末尾，后面跟着乱码文本（下一页的压缩版本）：
禁用压缩时，会发生同样的情况，显示重定向页面的末尾，然后显示后续页面。因为它是纯 HTML，所以 IE 会呈现它，并且显示如下：
显然 IE 不会检测重定向页面何时结束以及下一页开始。
我们在服务器上的 IIS 下运行 Python/Flask。
我们有完全相同的 IE 版本，其中一个浏览器会出现此问题，而另一种则不会。我们仔细比较了所有设置，但无法在有效的浏览器上重现问题，反之亦然。
我尝试更新执行实际重定向的Python库（Werkzeug），我更新了wfastcgi.py（将Python与IIS集成的组件），这两件事都没有什么区别。
我最终做了什么：
使用完整 URL 进行重定向在很多情况下都有效。因此，我们确保所有重定向都使用绝对 URL，而不是相对 URL。
之后，仍有一些重定向导致 IE 加载出现问题。
事实证明，这些重定向的末尾有一个日期（在查询字符串中）。我在最后添加了一个虚拟查询字符串参数，问题就消失了。
例如：
如果原始 URL 以
/diary?targetday=2018-01-01结尾，我会将其更改为/diary?targetday=2018-01-01&test=1< /code> 使其工作。希望这对某人有帮助。
Another tip for people experiencing this problem:
In my case certain installations of IE11 were not redirecting properly, others were (even the same exact versions of IE).
What happened when it doesn't work is that IE does not detect the end of the redirect page, and the beginning of the next page.
This manifests itself in the browser as a piece of HTML code of the end of the redirect page, directly followed by the content of the actual page that needed to be loaded.
If compression was enabled we would see the end of the redirect page followed by garbled text (the compressed version of the next page):
With compression disabled, the same thing happens, the end of the redirect page shows, and the follow-up page shows. Because it's plain HTML, IE renders it, and it shows up like this:
So clearly IE doesn't detect when the redirect page ends, and the next page begins.
We were running Python/Flask under IIS on the server.
We have the exact same versions of IE, where one browser would have this problem, and the other would not. We have meticulously compared all settings, but we could not reproduce the problem on the browser that worked or vice versa.
I have tried updating the Python library (Werkzeug) that performs the actual redirect, I have updated wfastcgi.py, the component that integrates Python with IIS, both of these things did not make a difference.
What I ended up doing:
Redirecting using the full URL worked in a lot of cases. So we made sure all of our redirects were using absolute URLs, and not relative.
After that, there were still some redirects left that IE had problems loading.
It turned out these redirects had a date at the end (in the querystring). I added a dummy querystring parameter at the end, and the problem was gone.
For example:
If the original URL ended with
/diary?targetday=2018-01-01, I would change it to/diary?targetday=2018-01-01&test=1to make it work.Hope this helps someone.