I am using Windows 7 Pro x64 and I am able to visit this site in Chrome without problems.

However, Internet Explorer (v 11.0.9600.17959) will just time out and show:

This page can’t be displayed.

I’m guessing it’s a configuration problem on my end. What did I break?

  • Does your IE accept cookies? Aug 29, 2015 at 9:23
  • I just tested your link in Opera 12.17, IE 11 (all settings on default), Chrome 46 and Firefox 35. The site takes some time to load, but all browsers, including IE were able to display the page. (Win7 x64 too, if it matters)
    – nixda
    Aug 29, 2015 at 13:08

4 Answers 4


Shorter answer

Based on the testing I have done, there is appears to be a 302 redirect loop happening when using curl to debug the site/URL. And that 302 redirect loop would cause the site to be unloadable in some browsers.

That said, curl is a fairly dumb HTTP testing tool which cannot handle cookies and based on HTTP headers sent back from the debugging process it seems like that website is endlessly trying to set a cookie on the client side. Which is not a good thing.

Knowing that, one can assume that if the site goes into a 302 redirect loop when it fails to set a cookie when testing with curl, perhaps your install of Internet Explorer 11 has something odd to it that is preventing the ivytech.edu server from setting a cookie as well? Which would then cause a 302 redirect loop condition on the server and then force the page to fail to load properly when Internet Explorer 11 runs into that 302 redirect loop.

Which is all to say I find the ivytech.edu server cookie/session setup to be problematic from a technical/“build-to-fail” point of view. And I believe that even if there is indeed an issue with your install of Internet Explorer 11, the ivytech.edu server cookie/session setup is a problem waiting to happen. And sadly, you happened to trip over that problem. Server connections should not fail like that due to their inability to connect to a client; that is bad engineering.

Longer answer

You say this:

I’m guessing it’s a configuration problem on my end. What did I break?

First, don’t blame yourself when you can blame always Internet Explorer! And in this case, don’t even blame Internet Explorer because it seems like there is something wrong with that website itself that Chrome allowed but Internet Explorer choked on. This is how I was able to diagnose it.

First, I went to the W3C Markup Validator to check the URL itself. And I received the following message:

Sorry! This document cannot be checked.

Which is basically the same as the message you are getting in Internet Explorer, but since the W3C Markup Validator is an HTML debugging tool it gave me more info:

Redirect loop detected (max_redirect = 7)

Aha! That’s the problem! The server itself is redirection the URL more than 7 times which is considered bad practice.

To do further debugging I opened up Terminal (I am on a Mac OS X machine) and tested that URL with curl like this:

curl -I -L http://cc.ivytech.edu/cp/home/displaylogin

The -I option to simply return bare HTTP headers and the -L tells curl to follow all redirects. And what I saw after that was the following endlessly looping between these two locations:

HTTP/1.1 302 Moved Temporarily
Server: nginx/1.6.2
Date: Sat, 29 Aug 2015 05:00:42 GMT
Content-Type: text/html
Content-Length: 160
Connection: close
Location: https://ccapps.ivytech.edu/cgi-bin/ccsession/session.cgi

HTTP/1.1 302 Found
Date: Sat, 29 Aug 2015 05:00:43 GMT
Server: Apache/2.2.15 (Red Hat)
Set-Cookie: CCSESSID=nWSdtHa8fQQSLmBsRYQZhalig3r5GYNW; domain=.ivytech.edu; path=/
Location: http://cc.ivytech.edu/cp/home/displaylogin
Connection: close
Content-Type: text/html; charset=iso-8859-1

Note how the first HTTP/1.1 302 Moved Temporarily redirects to https://ccapps.ivytech.edu/cgi-bin/ccsession/session.cgi which then sends back a HTTP/1.1 302 Found that then redirects to the first URL again, http://cc.ivytech.edu/cp/home/displaylogin. That is weird. There is no valid reason I know of for a web server to endlessly being looping URL locations like this.

So the issue is might not on your end. Somehow Chrome is working well with this odd server setup on the ivytech.edu server. But Internet Explorer is basically doing what it’s being told to do and then saying, “Hey, why is this redirecting like crazy? I give up.”

But I did say might, right?

Perhaps the issue is on the server at ivytech.edu or perhaps this is a cookie/session issue. Note that on the second hop the header is attempting to set a cookie via Set-Cookie: CCSESSID=nWSdtHa8fQQSLmBsRYQZhalig3r5GYNW; domain=.ivytech.edu; path=/. In curl that directive from the server will never be able to set a cookie since curl is a fairly “dumb” and simple HTTP testing tool; so maybe the inability for curl to set a cookie is causing the loop? And knowing that, one might deduce that something in your Internet Explorer 11 setup is causing cookie setup issues as well?

What this all means: There is might be nothing wrong on the client side; aka: your side. But maybe the web server at ivytech.edu that manages that website/URL has issues. And perhaps there is a cookie/session issue as well when it comes to your Internet Explorer 11 setup handling this website? I would consider contacting their tech support team and alerting them to this issue and maybe even point them to this thread for reference. Heck, for all you know this is a combo of their server setup as well as local cookie/session issues.

  • 4
    There's no problem in firefox.
    – RogUE
    Aug 29, 2015 at 5:44
  • 1
    @RogUE NoScript? No idea. All I know is what I posted and I am confident in my assessment. The error is not browser/client based by rather server based. For all I know Internet Explorer is the worst browser to handle 302 redirects. But the server itself is what is causing the initial issue. Aug 29, 2015 at 6:14
  • 1
    @Bob if it magically fixed itself I would hazard a guess that you discovered a corner case in their session management. Maybe you had an expired session cookie so the login handler detects that that redirects you to some sort of session validation and then the session validation detects that the cookie is expired and sends you back to login. Notice how the session CGI script is setting a cookie in the headers. That's all just a complete guess though. Aug 29, 2015 at 9:19
  • 1
    @JakeGould to me this looks like when you hit the login page the site sends you to session management script that attempts to set a cookie. It then sends you back to the login page. Now curl isn't sending that cookie back to the login page (no cookie header) so the cycle repeats itself. I would hazard a guess that the OP has cookies disabled in IE... Aug 29, 2015 at 9:25
  • 1
    @BoristheSpider Nice. Should always check the simple option first! (redirect loop occurs in FF with cookies disabled - I didn't notice the one-off redirect because I already had the cookie by the time I brought up the network monitor the first time)
    – Bob
    Aug 29, 2015 at 9:43

Recently we had similar issue where one of the website worked in Chrome and not in IE. Though the page was rendered, we were not able to login in IE. Finally the problem was that, the hostname has a "_" (underscore) in the URL which IE errored out. Once we renamed the site without underscope. Worked in both .


I tried all the solutions from here, also i tried enterprise mode the problem persisted.

what i had to do was to add the domain to the trusted sites in IE settings that resolved the problem like this *.subdomain.domain.com


Check the website isn't added to Compatibility View. Check the IE Tools - Compatibility View Settings. I was also having issues rendering in IE and not in Chrome, resulting in being unable to get the SAML response. This turned out to be the cause.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .