2012-06-21 33 views
11

EDIT 23-06-2012 10:24 (CET): Znaleziono odpowiedź@ font-face nie będzie ładować za pośrednictwem protokołu HTTPS w IE

Spójrz na dole odpowiedź. To właśnie naprawiło problem. IE9 renderuje teraz właściwą drogę. IE8 ma nieco inną czcionkę. Nie wiem, która czcionka, ale wygląda "OK".

Original Question:

mam zmaga się z tym przez kilka godzin teraz. Dla jednego z naszych klientów zaprojektowaliśmy sklep internetowy i rozwijaliśmy go poprzez normalne, niezabezpieczone połączenie http. Od 2 dni instalujemy certyfikat SSL w domenie i wymuszamy każde połączenie z witryną, aby przejść przez domenę https przy użyciu .htaccess

Jednak z jakiegoś powodu IE (bez wersji) renderuje czcionkę Określono w CSS za pomocą @ Font-Face. Oto na kodów używamy dla czcionek:

@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; 
} 

Jak widać używam pełny link do czcionek tym https. Próbowałem przenieść pliki do katalogu głównego domeny, aby dopasować domenę certyfikatów SSL. Próbowałem również użyć względnych ścieżek z poziomu CSS, ale także to nie zadziałało.

Wszystkie czcionki znajdują się w domenie, żadna z nich nie jest w domenie.

Natknąłem się na 2 inne posty tutaj na SO opisujące podobne problemy, jeden z nich nie został rozwiązany, drugi był, ale nie wydawał się być ten sam problem. W tym przypadku autor pytania musiał dodać nagłówki Access-Control-Allow-Origin do żądań plików woff/ttf/otf/svg. Dodałem te nagłówki do mojego pliku .htaccess, aby się upewnić:

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

Wyczerpany rodzaj opcji. Nie jestem typem serwerowym, ale bardziej w PHP/MySQL/jQuery, więc myślę, że moje myśli są raczej ograniczone w porównaniu do innych tutaj na SO.

Jeśli ktoś ma opcję, która jest warta wypróbowania, daj mi znać!

UPDATE 22-06-2012:

Jeśli zmienię https do http i odśwież stronę w IE, jestem potwierdzeniu z wiadomością, że jest niezabezpieczony zawartość i mam opcję, aby zaakceptować tę zawartość. Jeśli wybiorę "TAK", moje treści są ładowane i ... czcionka jest dostępna !! Yay .. Jednak .. jeśli zmienię go z powrotem na https, czcionki znikną ponownie.

Nie wiem, czego mogę się nauczyć od tego (lol), ale może to daje każdemu trochę pojęcia ..

UPDATE 22-06-2012 #2:

tej pory próbowałem:

url ('/ /protocol/relative/font.eot "); url ("../ plik/relacja/font.eot"); adres URL ("/ domain/relative/font.eot"); adres URL ("https: //www.secure.tld/font.eot"); adres URL ("http: //www.normal.tld/font.eot"); (działa, ale z wyskakującym okienkiem "Zawierające niezabezpieczone elementy w IE)

Próbowałem także stworzyć przepisanie wymuszające na plikach FilesMatch (woff, ttf, otf, eot, svg) połączenie http: //. działa tak jak myślałem i nie mam pojęcia, czy coś w ogóle zrobiło ...

Dodałem również to:

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

do folderu zawierającego czcionki (w plikach .htaccess oczywiście) aswell jak w głównym pliku .htaccess.

Poza tym próbowałem usunąć login htpasswd, było to dzikie domysły, ale też niczego nie zmieniłem.

UPDATE 23-06-2012:

sprawdzone logi serwera DirectAdmin .. widocznie IE żąda czcionek (widzę plik EOT z questionmark, zgaduję to EOT z iefix i WOFF jest wymagane). Wszystko, co wymagane jest również uzyskanie odpowiedzi 200 OK nagłówka, który nie jest tworzenie rzeczy bardziej jasne dla mnie ..

Wciąż szuka i szuka tego, co może być przyczyną tego problemu ..

Ponadto, w oparciu o " F12 Console Log "-wszystko w IE. Mogę wyraźnie zobaczyć, że żądane są czcionki - na https- z odpowiedzią 200 OK. Dziwne jest to, że widzę tylko 3 z 4 czcionek, których używam, ale możliwe, że czwarty nie jest używany na stronie głównej.

+1

Nie mogę wymyślić nic konkretnego, ale czy próbowałeś adresów URL bez domeny lub [protokołu względnych adresów URL] (http://paulirish.com/2010/the-protocol-relative-url/)? – RoToRa

+0

Jeszcze nie próbowałem adresów URL zależnych od protokołu, spróbuję. Adresy URL bez domeny lub względem CSS są wypróbowane i nie działały niefortunnie. –

+0

Czy możesz dowiedzieć się, że plik jest ładowany, na przykład z Fiddler? – RoToRa

Odpowiedz

2

Tak, właśnie odkryłem sposób, który działa na IE, Safara, Firefox i Chrome, o ile widzę.

Ponieważ wszystkie rzeczy, które wypróbowałem, nie wyszło, starałem się znaleźć sposób, który mógłby "osadzić" czcionki na moich stronach internetowych, w moim CSS lub na moim serwerze. Dodanie czcionki do mojego serwera nie było opcją według mojego serwera-faceta, więc zdecydowałem się wrócić do Font-Squirrel i sprawdzić, czy była dostępna opcja konwersji czcionek.

Ponownie załadowałem moje czcionki i wybrałem tryb eksportu. Gdzieś w dolnej części pól ustawień znajduje się "Kodowanie Base64", na szczęście wiedziałem, co to oznacza (mogę sobie wyobrazić kogoś, kto nie łatwo przegląda tę opcję), więc wybrałem moje pliki CSS z czcionkami wyodrębnionymi w base64.

To działa bezbłędnie. Oczywiście spowodowało to, że moje pliki CSS były większe (5kb vs 129kb). Ale nie widzę dużego plusu 100kB z obecnymi połączeniami internetowymi.

Dla porównania, non zakodowane base64 CSS:

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

Użyj 'application/font-woff', albo otrzymasz [Resource zinterpretowany jako Font, ale przeniesiony z aplikacją typu MIME/x- font-woff] (http://stackoverflow.com/questions/16704967/resource-interpreted-as-font-but-transferred-with-mime-type-application-x-font-w) ostrzeżenia. –

1

może zmusić go do pracy przy użyciu Webfont-Loader, opracowany przez Google i Typkit:

je dodać trochę nad głową, ale również daje większą kontrolę nad font-ładowanie (jak klas, które pozwalają na ustawienie różnych stylów podczas czcionki nie zostały jeszcze załadowane). Być może warto spróbować, setup for your own css seems to be simple.

+0

Ponieważ czcionki nie ładują się przy użyciu mojego własnego CSS, wątpię, żeby ładowały się za pomocą programu ładującego Webfont. Jednak w normalnym CSS mogę również ustawić kopię zapasową fontów. I tak zajrzę to, nigdy się nie dowiesz. Dzięki –

+0

Szkoda, nie działa :(IE wciąż jest trochę b * tch :( –

3

miałem dokładnie ten sam problem z IE i HTTPS. IE próbował załadować 3 z 4 czcionek, ale jak tylko serwer dostarczył zasób, IE zerwał i przeszedł do następnej czcionki. W końcu żadna czcionka nie została załadowana, a strona wyglądała fatalnie. W moim przypadku nagłówek http "pragma = no-cache" był tym, co myliło IE. Po usunięciu go z odpowiedzi wszystko działało sprawnie.Zobacz także mój wpis w blogu, który wyjaśnia sprawę z JBoss Application Server i Undertow: Blog

UPDATE:

W międzyczasie otworzył błąd w Microsoft Connect: https://connect.microsoft.com/IE/feedbackdetail/view/992569/font-face-not-working-with-internet-explorer-and-http-header-pragma-no-cache

Jeśli chcesz, aby rozwiązać ten problem, zagłosuj na błąd.

4

Zdecydowanie mając ten sam problem. Kombinacja IE (w naszej wersji sprawy 11/Trident 7) pojawia się błąd, gdy wszystkie warunki spotkać:

HTTPS, no-cache nagłówek

W niektórych dziedzinach, które są podawane oddzielnie, to nie jest łatwy problem Obejście

+0

jeden z możliwych sposobów obejście problemu polega na udostępnianiu plików czcionek z CDN – echen

+2

Dziękuję! straciłem dużo czasu na ten problem Zapisałeś mój czas! Naprawiono, skonfigurowałem w .htaccess jako Zestaw nagłówków Cache-Control "max -age = 604800, public. " Zestaw nagłówków Pragma" " –

+0

Tak, mogłem przezwyciężyć problem za pomocą proxy nginx, aby ukryć nagłówki kontroli i pamięci podręcznej, generowane przez wiosenny rozruch, zapobiegające buforowaniu w br. owser: [link] (http://stackoverflow.com/a/43093451/1767316) – user1767316

2

roztwór roboczy do Apache/2.2.15 jest dodanie .htaccess Jego zapobiega buforowanie fontowe nawet https

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

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

[link] (Korzystanie z nginx): ukrywanie kontroli Cache i Pragma: no-cache – user1767316

0

nie ustawiaj Vary nagłówka żądania hTTPS

Brak ładowania czcionki

Vary:Accept-Encoding,https 

Works

Vary:Accept-Encoding 

samą odpowiedź here.

Powiązane problemy