IE doesn't follow redirect, gives "Internet Explorer cannot display the webpage"

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 redi开发者_Go百科rect 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.

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:

 Connection: close

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.

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.

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:

header("location:http://www.test.co.uk/test/test.php");

or

header("location:test.php");

But started working when the command was amended to:

header("Location: http://www.test.co.uk/test/test.php");

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=1 to make it work.

Hope this helps someone.