Website works in Chrome but not in Internet Explorer





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}







3















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?










share|improve this question

























  • Does your IE accept cookies?

    – Boris the Spider
    Aug 29 '15 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 '15 at 13:08




















3















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?










share|improve this question

























  • Does your IE accept cookies?

    – Boris the Spider
    Aug 29 '15 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 '15 at 13:08
















3












3








3








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?










share|improve this question
















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?







internet-explorer website internet-explorer-11






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Aug 29 '15 at 4:54









JakeGould

32.9k10100142




32.9k10100142










asked Aug 29 '15 at 4:51









posfan12posfan12

2822517




2822517













  • Does your IE accept cookies?

    – Boris the Spider
    Aug 29 '15 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 '15 at 13:08





















  • Does your IE accept cookies?

    – Boris the Spider
    Aug 29 '15 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 '15 at 13:08



















Does your IE accept cookies?

– Boris the Spider
Aug 29 '15 at 9:23







Does your IE accept cookies?

– Boris the Spider
Aug 29 '15 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 '15 at 13:08







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 '15 at 13:08












3 Answers
3






active

oldest

votes


















7














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.






share|improve this answer





















  • 4





    There's no problem in firefox.

    – RogUE
    Aug 29 '15 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.

    – JakeGould
    Aug 29 '15 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.

    – Boris the Spider
    Aug 29 '15 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...

    – Boris the Spider
    Aug 29 '15 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 '15 at 9:43





















0














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 .






share|improve this answer































    -1














    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.






    share|improve this answer
























      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "3"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f964411%2fwebsite-works-in-chrome-but-not-in-internet-explorer%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      3 Answers
      3






      active

      oldest

      votes








      3 Answers
      3






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      7














      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.






      share|improve this answer





















      • 4





        There's no problem in firefox.

        – RogUE
        Aug 29 '15 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.

        – JakeGould
        Aug 29 '15 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.

        – Boris the Spider
        Aug 29 '15 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...

        – Boris the Spider
        Aug 29 '15 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 '15 at 9:43


















      7














      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.






      share|improve this answer





















      • 4





        There's no problem in firefox.

        – RogUE
        Aug 29 '15 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.

        – JakeGould
        Aug 29 '15 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.

        – Boris the Spider
        Aug 29 '15 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...

        – Boris the Spider
        Aug 29 '15 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 '15 at 9:43
















      7












      7








      7







      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.






      share|improve this answer















      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.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Aug 29 '15 at 15:50

























      answered Aug 29 '15 at 5:05









      JakeGouldJakeGould

      32.9k10100142




      32.9k10100142








      • 4





        There's no problem in firefox.

        – RogUE
        Aug 29 '15 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.

        – JakeGould
        Aug 29 '15 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.

        – Boris the Spider
        Aug 29 '15 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...

        – Boris the Spider
        Aug 29 '15 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 '15 at 9:43
















      • 4





        There's no problem in firefox.

        – RogUE
        Aug 29 '15 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.

        – JakeGould
        Aug 29 '15 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.

        – Boris the Spider
        Aug 29 '15 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...

        – Boris the Spider
        Aug 29 '15 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 '15 at 9:43










      4




      4





      There's no problem in firefox.

      – RogUE
      Aug 29 '15 at 5:44





      There's no problem in firefox.

      – RogUE
      Aug 29 '15 at 5:44




      1




      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.

      – JakeGould
      Aug 29 '15 at 6:14







      @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.

      – JakeGould
      Aug 29 '15 at 6:14






      1




      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.

      – Boris the Spider
      Aug 29 '15 at 9:19





      @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.

      – Boris the Spider
      Aug 29 '15 at 9:19




      1




      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...

      – Boris the Spider
      Aug 29 '15 at 9:25





      @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...

      – Boris the Spider
      Aug 29 '15 at 9:25




      1




      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 '15 at 9:43







      @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 '15 at 9:43















      0














      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 .






      share|improve this answer




























        0














        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 .






        share|improve this answer


























          0












          0








          0







          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 .






          share|improve this answer













          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 .







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jul 14 '17 at 17:22









          JeevJeev

          11




          11























              -1














              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.






              share|improve this answer




























                -1














                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.






                share|improve this answer


























                  -1












                  -1








                  -1







                  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.






                  share|improve this answer













                  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.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Feb 12 at 2:08









                  NatashaNatasha

                  1




                  1






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Super User!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f964411%2fwebsite-works-in-chrome-but-not-in-internet-explorer%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      Список кардиналов, возведённых папой римским Каликстом III

                      Deduzione

                      Mysql.sock missing - “Can't connect to local MySQL server through socket”