2012-06-21 11 views
11

EDIT 23-06-2012 10:24 (CET): trovato la risposta@ font-face non viene caricato tramite https in IE

Date un'occhiata alla risposta di fondo. Questo è ciò che ha risolto il problema per me. IE9 sta rendendo la strada giusta ora. IE8 ha un font leggermente diverso. Non sei sicuro di quale font, ma sembra "OK".

Original Question:

ho lottato con questo per diverse ore ormai. Per uno dei nostri clienti abbiamo progettato un webshop e lo abbiamo sviluppato con una connessione http non protetta normale. Da 2 giorni, abbiamo installato un certificato SSL sul dominio e forzato ogni connessione con il sito web per passare il dominio https utilizzando .htaccess

Ma, per qualche motivo, IE (nessuna versione) restituisce il carattere che noi specificato nel CSS usando @ Font-Face. Ecco su dei codici che stiamo usando per i font:

@font-face { 
    font-family: 'ProximaNovaLight'; 
    src: url('https://www.bijouterieyvette.com/font-face/proximanova-light-webfont.eot'); 
    src: url('https://www.bijouterieyvette.com/font-face/proximanova-light-webfont.eot?#iefix') format('embedded-opentype'), 
     url('https://www.bijouterieyvette.com/font-face/proximanova-light-webfont.woff') format('woff'), 
     url('https://www.bijouterieyvette.com/font-face/proximanova-light-webfont.ttf') format('truetype'), 
     url('https://www.bijouterieyvette.com/font-face/proximanova-light-webfont.svg#ProximaNovaLight') format('svg'); 
    font-weight: normal; 
    font-style: normal; 
} 

Come potete vedere sto usando il link completo ai font tra cui il https. Ho provato a spostare i file nella directory principale del dominio in modo che corrisponda al dominio dei certificati SSL. Ho anche provato a utilizzare percorsi relativi all'interno del CSS, ma anche questo non ha funzionato.

Tutti i tipi di carattere sono nel dominio, nessuno di essi è di dominio incrociato.

Mi sono imbattuto in altri 2 post qui su SO che descrivono problemi simili, uno dei non è stato risolto, l'altro era, ma non sembrava essere lo stesso problema. In questo caso l'autore della domanda ha dovuto aggiungere intestazioni Access-Control-Allow-Origin alle richieste di file di woff/ttf/otf/svg. Ho anche aggiunto queste intestazioni al mio .htaccess solo per essere sicuri:

<FilesMatch "\.(woff|ttf|otf|svg)$"> 
    <IfModule mod_headers.c> 
     Header set Access-Control-Allow-Origin "*" 
    </IfModule> 
</FilesMatch> 

Sono un po 'a corto di opzioni e thoughs. Non sono un tipo di configurazione del tipo di server, ma più in PHP/MySQL/jQuery, quindi credo che i miei pensieri siano piuttosto limitati rispetto ad altri qui su SO.

Se qualcuno ha un'opzione che vale la pena provare, fammelo sapere!

UPDATE 22-06-2012:

Se cambio i https a http e aggiornare la pagina in IE, mi viene richiesto con il messaggio che v'è contenuto non sicuro e ho la possibilità di accettare questo contenuto. Se scelgo 'SÌ', il mio contenuto viene caricato e ... il carattere è disponibile !! Sì .. Comunque .. se lo cambio di nuovo a https i caratteri scompaiono di nuovo.

Non so cosa posso imparare da questo (lol), ma forse questo dà a chiunque una piccola idea ..

UPDATE 22-06-2012 #2:

Finora ho provato:

url ('/ /protocol/relative/font.eot '); url ('../ file/relativo/font.eot'); url ('/ domain/relative/font.eot'); url ('https: //www.secure.tld/font.eot'); url ('http: //www.normal.tld/font.eot'); (funziona ma con un popup "Contenenti articoli non protetti in IE)

Ho anche provato a creare un rewriterule forzando il FilesMatch (woff, ttf, otf, eot, svg) a una connessione http: //. lavoro come pensavo e non ho idea se non ha fatto nulla ..

ho anche aggiunto questo:

AddType application/vnd.ms-fontobject .eot 
AddType font/truetype .ttf 
AddType font/opentype .otf 
AddType font/opentype .woff 
AddType image/svg+xml .svg .svgz 

alla cartella contenente i font (in una file .htaccess ofcourse) proprio come nel file .htaccess principale.

Oltre a questo ho provato a rimuovere il login htpasswd, era una supposizione sfrenata, ma non ha cambiato nulla.

UPDATE 23-06-2012:

controllato i log del server DirectAdmin .. a quanto pare IE sta richiedendo i font (vedo un file di EOT con il punto interrogativo, sto cercando di indovinare questo è l'EOT con l'essere richiesti iefix e WOFF). Tutto ciò che è richiesto è anche ottenere una risposta 200 OK colpo di testa, che non sta facendo le cose più chiaro per me ..

Ancora alla ricerca e alla ricerca di quello che potrebbe causare questo problema ..

Inoltre, sulla base del " F12 Console Log "-thingy in IE. Posso vedere chiaramente che i caratteri vengono richiesti -over https- con una risposta di 200 OK. Stranamente, vedo solo 3 dei 4 tipi di carattere che sto utilizzando, ma è possibile che il 4 non venga utilizzato nella pagina principale.

+1

Non riesco a pensare a qualcosa di specifico, ma hai provato URL senza un dominio, o [URL relativi al protocollo] (http://paulirish.com/2010/the-protocol-relative-url/)? – RoToRa

+0

Non ho ancora provato gli URL relativi ai protocolli, ci proverò. Gli URL senza dominio o relativo al CSS vengono provati e non funzionano sfortunatamente –

+0

Puoi scoprire che il file viene caricato, ad esempio con Fiddler? – RoToRa

risposta

2

Quindi, ho appena trovato un modo che funziona per IE, Safara, Firefox e Chrome, per quanto posso vedere.

Dal momento che tutte le cose che ho provato non funzionavano, stavo cercando di trovare un modo per "incorporare" i caratteri sui miei siti web, sul mio CSS o sul mio server. Aggiunto il font al mio server non era un'opzione in base al mio server-guy, quindi ho deciso di tornare a Font-Squirrel e vedere se c'era un'opzione che offrivano nella conversione dei font.

Ho ricaricato i miei caratteri e ho scelto la modalità di esportazione. Da qualche parte nella parte inferiore dei campi delle impostazioni dice "Base64 Encode", fortunatamente sapevo cosa significava (posso immaginare qualcuno che non guarda facilmente questa opzione) così ho generato i miei file CSS con i font embdedded base64.

Questo funziona perfettamente. Ovviamente questo ha reso i miei file CSS più grandi di kb (5kb contro 129kb). Ma non vedo un grande aumento di 100kb in più con le attuali connessioni Internet.

CSS Basta mettere a confronto, non Base64 codificati:

@font-face { 
    font-family: 'ProximaNovaSemibolds'; 
    src: url('../font-face/proximanova-semibold-webfont.eot'); 
    src: url('../font-face/proximanova-semibold-webfont.eot?#iefix') format('embedded-opentype'), 
     url('../font-face/proximanova-semibold-webfont.woff') format('woff'), 
     url('../font-face/proximanova-semibold-webfont.ttf') format('truetype'), 
     url('../font-face/proximanova-semibold-webfont.svg#ProximaNovaSemibold') format('svg'); 
    font-weight: normal; 
    font-style: normal; 
} 

Base64 codifica CSS:

@font-face { 
    font-family: 'ProximaNovaBold'; 
    src: url('proximanova-bold-webfont-webfont.eot'); 
    } 

@font-face { 
    font-family: 'ProximaNovaBold'; 
    src: url(data:application/x-font-woff;charset=utf-8;base64,d09GRgABAAAAAF+8ABMAAAAArzAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAABGRlRNAAABqAAAABwAAAAcYT+YZ0dERUYAAAHEAAAALQAAADIC+wHsR1BPUwAAAfQAAAf7AAAURoqljoZHU1VCAAAJ8AAAACAAAAAgbJF0j09TLzIAAAoQAAAAWwAAAGB+FsNBY21hcAAACmwAAAGdAAAB+uY47ZljdnQgAAAMDAAAADoAAAA..alotmorecharacters...FDmYlYoTkE8HdsTFF2cwU74AAU/lecUAAA==) format('woff'), 
     url('proximanova-bold-webfont-webfont.ttf') format('truetype'), 
     url('proximanova-bold-webfont-webfont.svg#ProximaNovaBold') format('svg'); 
    font-weight: normal; 
    font-style: normal; 

} 
+0

Usa 'application/font-woff', o otterrai [Risorsa interpretata come Font ma trasferita con applicazione tipo MIME/x- font-woff] (http://stackoverflow.com/questions/16704967/resource-interpreted-as-font-but-transferred-with-mime-type-application-x-font-w) warnings –

1

Si può farlo funzionare utilizzando il Webfont-Loader, sviluppato da Google e Typkit:

E aggiungere un po 'in testa, ma ti dà anche un maggiore controllo sui font-carico (come le classi che consentono di impostare diversi stili, mentre i caratteri non sono ancora stati caricati). Forse vale la pena provare, setup for your own css seems to be simple.

+0

Poiché i caratteri non vengono caricati utilizzando il mio CSS, dubito che vengano caricati utilizzando il caricatore webfont. Tuttavia, in normale CSS posso anche impostare un font di backup. Ne darò uno sguardo comunque, non lo saprai mai. Grazie –

+0

Peccato, non ha funzionato :(IE è ancora un po 'b * tch :( –

3

Ho avuto esattamente lo stesso comportamento con IE e https. IE ha provato a caricare 3 dei 4 tipi di carattere, ma non appena il server ha consegnato la risorsa, IE si è interrotto e si è spostato sul carattere successivo. Finalmente nessun carattere è stato caricato e il sito sembrava schifoso. Nel mio caso l'intestazione http "pragma = no-cache" era la cosa che confondeva IE. Dopo averlo rimosso dalla risposta, tutto ha funzionato senza intoppi.Vedi anche il mio blog che spiega il trucco con wildfly e Undertow: Blog

UPDATE:

Nel frattempo ho aperto un bug a Microsoft Connect: https://connect.microsoft.com/IE/feedbackdetail/view/992569/font-face-not-working-with-internet-explorer-and-http-header-pragma-no-cache

Se si desidera loro di risolvere il problema, per favore vota per il bug.

4

Definitivamente lo stesso problema. Una combinazione di IE (nella nostra versione caso 11/Trident 7) Bug si verifica quando tutte le condizioni si incontrano:

HTTPS, no-cache intestazione

Su alcuni domini che vengono somministrati a parte, questo non è un problema facile da soluzione

+0

un modo possibile per aggirare il problema è quello di servire i file di carattere da un CDN – echen

+2

Grazie! Mi è stato perso molto tempo per questo problema.Il mio tempo mi è stato salvato! Per risolvere, ho configurato in .htaccess come Header set Cache-Control "max -age = 604800, pubblico. " Header set Pragma" " –

+0

Sì, potrei risolvere il problema usando il proxy nginx per nascondere le intestazioni pragma e controllo cache che vengono generate da spring-boot che impediscono il caching nella memoria owser: [link] (http://stackoverflow.com/a/43093451/1767316) – user1767316

2

soluzione di lavoro per Apache/2.2.15 è quello di aggiungere .htaccess le sue impedisce la memorizzazione nella cache di carattere file anche per https

<FilesMatch "\.(woff)$"> 
    Header unset Cache-control 
</FilesMatch> 

<FilesMatch "\.(eot)$"> 
    Header unset Cache-control 
</FilesMatch> 
+0

[link] (Uso di nginx): nasconde sia il controllo della cache che Pragma: no-cache – user1767316

0

non si imposta la richiesta di intestazione Vary a https

Nessun carattere carico

Vary:Accept-Encoding,https 

Opere

Vary:Accept-Encoding 

stessa risposta here.

Problemi correlati