IE9 bloqueia o download da fonte da web de origem cruzada

Isto está me enlouquecendo.

Apenas testando um site no IE9 e descobri que a versão ‘live’ está renderizando uma fonte da web que estou usando menor que na versão dev.

Aqui está uma seleção de screen grabs:

insira a descrição da imagem aqui

Eu estou usando o kit Font-Squirrel @ font-face. Como você pode ver, está tudo bem no Firefox, Chrome e até no IE9 ao visualizar uma versão local do site.

A única diferença entre as versões local e live é que a fonte está sendo carregada de um domínio diferente no site ativo (configurei a política de vários domínios corretamente, conforme ilustrado pelo fato de ela funcionar no Firefox e no Chrome).

Não me lembro como ele era no IE8 (a Microsoft, mais uma vez, não pensou em desenvolvedores e instalou o IE9 no topo do IE8 sem a opção de executá-los simultaneamente)

O site está em http://enplanner.com para que você possa visualizar a fonte.

Qualquer ajuda sobre isso seria muito apreciada – agradeço antecipadamente.

Edit: Eu removi IE9 e descobri que é exatamente o mesmo em ambos os locais e vivem no IE8. Parece que o IE8 tem um mecanismo de renderização superior mais próximo do FF / Chrome do que o IE9. Esta é uma descoberta bastante deprimente.

    IE9 suporta .WOFF; IE8 não, e suporta apenas fonts .EOT.

    Abra o IE9 F12 Developer Tools e você verá as seguintes mensagens:

    CSS3117: @font-face failed cross-origin request. Resource access is restricted. Neuton-webfont.woff CSS3117: @font-face failed cross-origin request. Resource access is restricted. YanoneKaffeesatz-Regular-webfont.woff CSS3114: @font-face failed OpenType embedding permission check. Permission must be Installable. Neuton-webfont.ttf CSS3114: @font-face failed OpenType embedding permission check. Permission must be Installable. YanoneKaffeesatz-Regular-webfont.ttf 

    Examinando os headers HTTP, fica claro que o access entre domínios não está configurado corretamente, pois não há header de resposta Access-Control-Allow-Origin nos arquivos WOFF. Eles também são entregues com o tipo MIME errado ( text/plain ), embora isso não esteja causando o seu problema. No entanto, a falha em mapear o woff para o tipo MIME correto pode causar problemas, pois alguns servidores não servirão arquivos com extensões “indefinidas” e, em vez disso, retornarão um erro HTTP/404 .

    OK, aqui está o que funcionou. Coloque a seguinte seção na sua configuração do Apache para o host que você está servindo as fonts de:

       Header set Access-Control-Allow-Origin "http://mydomain.com"   

    Substitua ‘mydomain.com’ por seu próprio domínio ou * (mas tenha cuidado ao usar * pois isso significa que qualquer pessoa pode usar seu CDN)

    O ‘woff’ era o que eu tinha esquecido. Doh!

    Para IIS Adicione as linhas abaixo …. funciona como um encanto


              

    Em relação à resposta do meanstreakuk acima, eu gostaria de complementar. Tivemos o mesmo problema e pesquisamos o que o Google Web Font faz. Então, colocamos no nosso htaccess, isto:

    Conjunto de headers Access-Control-Allow-Origin “*”

    em vez do nosso domínio. Se o asterisco, como o Google faz, funciona o tempo todo.

    Verifique se você pode abrir no IE o arquivo (your-web.com/your-font.woff), Se você receber erro 404 vá para o IIS, clique duas vezes na opção de configuração “MIME Types” (Tipos MIME) enquanto o nó raiz do IIS é selecionado no painel esquerdo e clique no link “Adicionar …” no painel Ações à direita. Isso trará a seguinte checkbox de diálogo. Adicionar . woff file extension e especifique ” application / x-font-woff ” como o tipo MIME correspondente.

    Eu uso essas instruções neste site ( Robòtica educativa ), eu converto minha fonte .ttf original em ( http://www.font2web.com/ )

    Eu encontrei uma solução alternativa. Adicionado isso ao htaccess.

     BrowserMatch MSIE best-standards-support Header set X-UA-Compatible IE=8 env=best-standards-support 

    Uma solução alternativa para usar o header Access-Control-Allow-Origin é embutir a fonte no seu CSS usando data :.

    Também vale a pena notar que, se seus ativos estiverem hospedados no Amazon AWS S3, você não poderá definir os headers enviados pelo servidor. Em vez disso, você precisará definir as configurações do CORS no seu bucket, de acordo com estas instruções:

    Não esqueça de include .svg – isso pode ser necessário em alguns casos. Adicioná-lo resolveu o problema no IE 11

       Header set Access-Control-Allow-Origin "*"   

    Para implementar no asp.net você pode usar essa syntax

     Response.AppendHeader("Access-Control-Allow-Origin", "*"); 

    Eu tentei de tudo, desde modificar minha configuração do apache e arquivos .htaccess sem sorte. Nas ferramentas de desenvolvimento do IE, tropecei no “Document Mode” e o padrão era IE7. Então, depois de alguma pesquisa, encontrei esta meta tag:

      

    Agora, o IE 10 e o 9 formatam meu site corretamente e exibem todos os icons do Font Awesome corretamente.

    Espero que ajude…

    NÃO TESTADO!
    Nginx site bit de arquivo para permitir apenas o access de origem para arquivos de fonte, se o seu CDN não é público 🙂 Codificação feliz

     location ~ \.(ttf|otf|eot|woff)$ { Access-Control-Allow-Origin: * } 

    Depois de perceber esse erro no console (F12): @font-face failed cross-origin request. Resource access is restricted @font-face failed cross-origin request. Resource access is restricted Descobri que meu navegador (IE11, emulação: IE9) ” bloqueou conteúdo para ajudar a proteger minha privacidade “. Ao desbloquear o conteúdo – clique no sinal ao lado do URL – ele funcionou como deveria.