Resposta mais curta
Com base nos testes que fiz, parece haver um loop de redirecionamento 302 acontecendo ao usar curl para depurar o site / URL. E esse loop de redirecionamento 302 faria com que o site fosse descarregável em alguns navegadores.
Dito isso, curl é uma ferramenta de teste HTTP bastante burra que não pode manipular cookies e com base em cabeçalhos HTTP enviados do processo de depuração parece que o site está tentando indefinidamente definir um cookie no lado do cliente. O que não é bom.
Sabendo disso, pode-se supor que, se o site entrar em um loop de redirecionamento 302 quando falhar ao definir um cookie ao testar com curl , talvez sua instalação do Internet Explorer 11 tenha algo estranho que esteja impedindo o ivytech.edu server de configurar um cookie também? O que então causaria uma condição de loop de redirecionamento 302 no servidor e forçaria a página a não carregar corretamente quando o Internet Explorer 11 for executado nesse loop de redirecionamento 302.
O que é tudo para dizer que eu acho que a configuração do cookie / sessão do servidor ivytech.edu é problemática do ponto de vista técnico / "construir para falhar". E acredito que, mesmo que haja realmente um problema com sua instalação do Internet Explorer 11, a configuração do cookie / sessão do servidor ivytech.edu é um problema que está prestes a acontecer. E, infelizmente, você passou por cima desse problema. Conexões de servidor não devem falhar assim devido à sua incapacidade de se conectar a um cliente; isso é engenharia ruim.
Resposta mais longa
Você diz isso:
I’m guessing it’s a configuration problem on my end. What did I break?
Primeiro, não se culpe quando puder culpar sempre o Internet Explorer! E, nesse caso, não sequer culpam o Internet Explorer porque parece que há algo errado com o próprio site que o Chrome permitiu, mas o Internet Explorer engasgou. Foi assim que consegui diagnosticar.
Primeiro, fui para o W3C Markup Validator para verificar o próprio URL . E recebi a seguinte mensagem:
Sorry! This document cannot be checked.
O que é basicamente o mesmo que a mensagem que você está recebendo no Internet Explorer, mas como o W3C Markup Validator é uma ferramenta de depuração de HTML, ele me forneceu mais informações:
Redirect loop detected (max_redirect = 7)
Aha! Esse é o problema! O próprio servidor redireciona a URL mais de 7 vezes, o que é considerado uma prática ruim.
Para fazer mais depuração, abri o Terminal (estou em uma máquina Mac OS X) e testei essa URL com curl assim:
curl -I -L http://cc.ivytech.edu/cp/home/displaylogin
A opção -I simplesmente retorna cabeçalhos HTTP e a -L informa a curva para seguir todos os redirecionamentos. E o que vi depois disso foi o seguinte interminável loop entre esses dois locais:
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
Observe como o primeiro HTTP/1.1 302 Moved Temporarily redireciona para https://ccapps.ivytech.edu/cgi-bin/ccsession/session.cgi , que envia de volta um HTTP/1.1 302 Found que redireciona para o primeiro URL novamente, http://cc.ivytech.edu/cp/home/displaylogin . Isso é estranho. Não há nenhuma razão válida que conheço para um servidor da Web ser interminavelmente em loop de locais de URL como este.
Portanto, o problema não é possível . De alguma forma, o Chrome está funcionando bem com essa configuração de servidor ímpar no servidor ivytech.edu . Mas o Internet Explorer basicamente está fazendo o que é dito para fazer e, em seguida, dizendo: "Ei, por que isso está redirecionando como um louco? Eu desisto ".
Mas eu disse poder , certo?
Talvez o problema esteja no servidor em ivytech.edu ou talvez seja um problema de cookie / sessão. Observe que, no segundo salto, o cabeçalho está tentando definir um cookie por meio de Set-Cookie: CCSESSID=nWSdtHa8fQQSLmBsRYQZhalig3r5GYNW; domain=.ivytech.edu; path=/ . Em curl essa diretiva do servidor nunca será capaz de definir um cookie, pois curl é uma ferramenta de teste de HTTP bastante “estúpida” e simples; então talvez a incapacidade de curl para definir um cookie está causando o loop? E sabendo disso, pode-se deduzir que algo em sua configuração do Internet Explorer 11 está causando problemas de configuração de cookies também?
O que isso significa: pode não haver nada de errado no lado do cliente; aka: seu lado. Mas talvez o servidor da Web em ivytech.edu que gerencia esse site / URL tenha problemas. E talvez haja um problema de cookie / sessão, bem como quando se trata de sua configuração do Internet Explorer 11 lidar com este site? Eu consideraria entrar em contato com sua equipe de suporte técnico e alertá-los sobre esse problema e talvez até mesmo apontá-los para esse segmento para referência. Heck, por tudo o que você sabe, esta é uma combinação de sua configuração de servidor, bem como problemas locais de cookies / sessão.