What mime type should WOFF fonts be served as?
I am serving truetype (ttf) fonts as font/truetype and opentype (otf) as font/opentype, but I cannot find the correct format for WOFF fonts.
I have tried font/woff, font/webopen, and font/webopentype, but Chrome still complains:
"Resource interpreted as font but transferred with MIME type application/octet-stream."
Anybody know?
Update from Keith Shaw's comment on Jun 22, 2017:
As of February 2017, RFC8081 is the proposed standard. It defines a top-level media type for fonts, therefore the standard media type for WOFF and WOFF2 are as follows:
font/woff
font/woff2
In January 2011 it was announced that in the meantime Chromium will recognize
application/x-font-woff
as the mime-type for WOFF. I know this change is now in Chrome beta and if not in stable yet, it shouldn't be too far away.
For me, the next has beeen working in an .htaccess file.
AddType font/ttf .ttf
AddType font/eot .eot
AddType font/otf .otf
AddType font/woff .woff
AddType font/woff2 .woff2
It will be application/font-woff.
see http://www.w3.org/TR/WOFF/#appendix-b (W3C Candidate Recommendation 04 August 2011)
and http://www.w3.org/2002/06/registering-mediatype.html
From Mozilla css font-face notes
In Gecko, web fonts are subject to the same domain restriction (font files must be on the same domain as the page using them), unless HTTP access controls are used to relax this restriction.
Note: Because there are no defined MIME types for TrueType, OpenType, and WOFF fonts, the MIME type of the file specified is not considered.
source: https://developer.mozilla.org/en/CSS/#font-face#Notes
Reference for adding font mime types to .NET/IIS
via web.config
<system.webServer>
<staticContent>
<!-- remove first in case they are defined in IIS already, which would cause a runtime error -->
<remove fileExtension=".woff" />
<remove fileExtension=".woff2" />
<mimeMap fileExtension=".woff" mimeType="font/woff" />
<mimeMap fileExtension=".woff2" mimeType="font/woff2" />
</staticContent>
</system.webServer>
via IIS Manager
NGINX SOLUTION
file
/etc/nginx/mime.types
or
/usr/local/nginx/conf/mime.types
add
font/ttf ttf;
font/opentype otf;
font/woff woff;
font/woff2 woff2;
application/vnd.ms-fontobject eot;
remove
application/octet-stream eot;
REFERENCES
RFC #02.2017
https://www.rfc-editor.org/rfc/rfc8081#page-15
https://www.iana.org/assignments/media-types/media-types.xhtml
Thanks to Mike Fulcher
http://drawingablank.me/blog/font-mime-types-in-nginx.html
As of February 2017, RFC8081 is the proposed standard. It defines a top-level media type for fonts, therefore the standard media type for WOFF and WOFF2 are as follows:
font/woff
font/woff2
Note: This answer was correct at it's time but became outdated in 2017 when RFC 8081 was released
There is no font MIME type! Thus, font/xxx is ALWAYS wrong.
Add the following to your .htaccess
AddType font/woff woff
good luck
Thing that did it for me was to add this to my mime_types.rb initializer:
Rack::Mime::MIME_TYPES['.woff'] = 'font/woff'
and wipe out the cache
rake tmp:cache:clear
before restarting the server.
Source: https://github.com/sstephenson/sprockets/issues/366#issuecomment-9085509
#Nico,
Currently there is no defined standard for the woff font mime type. I use a font delivery cdn service and it uses font/woff and I get the same warning in chrome.
Reference: The Internet Assigned Numbers Authority
https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Complete_list_of_MIME_types
This is a helpful list of mimetypes
I know this post is kind of old but after spending many hours on trying to make the fonts work on my nginx local machine and trying a tons of solutions i finally got the one that worked for me like a charm.
location ~* \.(eot|otf|ttf|woff|woff2)$ {
add_header Access-Control-Allow-Origin *;
}
Inside the parenthesis you can put the extensions of your fonts or generally the files that you want to load. For example i used it for fonts and for images(png,jpg etc etc) as well so don't get confused that this solution applies only for fonts.
Just put it into your nginx config file, restart and i hope it works also for you!
Maybe this will help someone. I saw that on IIS 7 .ttf is already a known mime-type. It's configured as:
application/octet-stream
So I just added that for all the CSS font types (.oet, .svg, .ttf, .woff) and IIS started serving them. Chrome dev tools also do not complain about re-interpreting the type.
Cheers,
Michael
For all Solution index.php remove form url and woff file allowed. for write below code in .htaccess file and and make this alternation to your application/config/config.php file:
$config['index_page'] = '';
For only Linux hosting server.
.htaccess file details
AddType font/ttf .ttf
AddType font/eot .eot
AddType font/otf .otf
AddType font/woff .woff
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
#Removes access to the system folder by users.
#Additionally this will allow you to create a System.php controller,
#previously this would not have been possible.
#'system' can be replaced if you have renamed your system folder.
RewriteCond %{REQUEST_URI} ^system.*
RewriteRule ^(.*)$ /index.php?/$1 [L]
#When your application folder isn't in the system folder
#This snippet prevents user access to the application folder
#Submitted by: Fabdrol
#Rename 'application' to your applications folder name.
RewriteCond %{REQUEST_URI} ^application.*
RewriteRule ^(.*)$ /index.php?/$1 [L]
#Checks to see if the user is attempting to access a valid file,
#such as an image or css document, if this isn't true it sends the
#request to index.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?/$1 [L]
</IfModule>
<IfModule !mod_rewrite.c>
# If we don't have mod_rewrite installed, all 404's
# can be sent to index.php, and everything works as normal.
# Submitted by: ElliotHaughin
ErrorDocument 404 /index.php
</IfModule>
IIS automatically defined .ttf as application/octet-stream which seems to work fine and fontshop recommends .woff to be defined as application/octet-stream
WOFF:
Web Open Font Format
It can be compiled with either TrueType or PostScript (CFF) outlines
It is currently supported by FireFox 3.6+
Try to add that:
AddType application/vnd.ms-fontobject .eot
AddType application/octet-stream .otf .ttf
Mime type might not be your only problem. If the font file is hosted on S3 or other domain, you may additionally have the issue that Firefox will not load fonts from different domains. It's an easy fix with Apache, but in Nginx, I've read that you may need to encode your font files in base-64 and embed them directly in your font css file.
Related
Im trying to get icomoon fonts working. locally they work fine but on the server (sitefinity) they don't work.
I have tried using .htaccess with the following but it does not work.
AddType application/vnd.ms-fontobject .eot
AddType application/x-font-opentype .otf
AddType image/svg+xml .svg
AddType application/x-font-ttf .ttf
AddType application/font-woff .woff
AddType application/font-woff2 .woff2
<IfModule mod_headers.c>
<FilesMatch ".(eot|otf|svg|ttf|woff2?)$">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
</IfModule>
This is the error i see:
No 'Access-Control-Allow-Origin' header is present on the requested resource.
I'm confused - is that .htaccess on the Sitefinity server that's hosting those fonts, or is it on your server (of your webpage that's trying to access the fonts from Sitefinity)?
If you're trying to access fonts on another site, it has to be that site that returns the ACAO response header (with the font itself).
If you can provide an example request for a font file, that might help, but TBH, CORS was pretty much designed so that people couldn't just include fonts from a 3rd-party (a 'font factory') on their own site. So I suspect that in this case, your webpage is trying to get the fonts from Sitefinity, the browser is passing the Origin request header with the GET request for the font, and Sitefinity is refusing to return the ACAO response header, so your webpage won't display the fonts.
I'm now hosting my website off my personal NAS drive and everything seems to be working except the SVGs.
I tried adding the .htaccess file with:
AddType image/svg+xml svg svgz
AddEncoding gzip svgz
but they still do not work. When I go to the URL of the file it just shows an error as if the file does not exist.
Any ideas?
Thanks in advance!
I have a project without a .htaccess(I already found solutions when you have a .htaccess in your project) and it is not displaying my .svg. Normal images are displayed correctly. The error message is as follows:
Resource interpreted as image but transferred with MIME type text/xml.
I am using xampp on osx yosemite version 10.10.1. Can I add
AddType image/svg+xml svg svgz
AddEncoding gzip svgz
somewhere in my xampp?
Thanks in advance!
Edit: I reinstalled xampp and that solved the problem. I will leave this open, in case people step over this problem again and one of the answers might be the right one.
It appears that you can add the appropriate mime type definitions to the following location depending on your OS:
xampp\apache\conf\mime.types or /etc/httpd/conf/mime.types
Note that the config file you're looking for is called mime.types
The definition you'd want to add would be something like:
image/svg+xml svg svgz
More info:
1. Thread on the topic
2. Blog post on the topic
I'm doing some website optimisations using PageSpeed. I faced a next suggestion:
The following resources have no character set specified in their HTTP
headers. Specifying a character set in HTTP headers can speed up
browser rendering.
http://localhost:8892/.../FocoBold.woff2
http://localhost:8892/.../FocoRegular.woff2
http://localhost:8892/.../GTblack.woff2
I've instantly started google and found a relevant answer on StackOverFlow.
I've added next line to .htaccess but it didn't worked for me.
AddDefaultCharset UTF-8
Next thing I've tried, but still no results.
AddType font/woff2 .woff2
Can anyone help me with that?
Thank you in advance
I was having the same problem.
I think that pagespeed is misreporting the underlying cause which is not so much a lack of definition of the charset, but a lack of definition of the content-type. Without that's being defined, it / most browsers assume what is being sent back is text/html, where, indeed, no charset has been defined, especially as the .woff2 file will contain "non-standard" (ASCII!) chars.
My solution (it may not work if your apache environment is significantly different, such as not allowing addtype in .htaccess files) was to add the following to the .htaccess in the relevant root of the site being served:
AddType application/x-font-woff2 .woff2
(Found this resource)
Worked for me!
.htaccess
In .htaccess AddType should be in mod_mime.c module
<IfModule mod_mime.c>
AddType application/woff2 .woff2
</IfModule>
I've recently tried to optimize my site for speed and brandwith. Amongst many other techniques, I've used GZIP on my .css and .js files.
Using PuTTY I compressed the files on my site and then used:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{HTTP_USER_AGENT} !Konqueror
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule ^(.*)\.css$ $1.css.gz [QSA,L]
RewriteRule ^(.*)\.js$ $1.js.gz [QSA,L]
<FilesMatch \.css\.gz$>
ForceType text/css
</FilesMatch>
<FilesMatch \.js\.gz$>
ForceType text/javascript
</FilesMatch>
</IfModule>
<IfModule mod_mime.c>
AddEncoding gzip .gz
</IfModule>
in my .htaccess file so that they get served properly because all my links are without the ".gz".
My problem is, I cant work on the GZIP file in Dreamweaver. Is there a plugin or extension of somesort that allows Dreamweaver to temporarily uncompress thses files so it can read them?
Or is there a way that I can work on my local copies as regular files, and server side they automatically get compressed when they are uploaded.
Or is there a different code editor I should be using that would completely get around this?
Or a just a different technique to doing this?
I hope this question makes sense,
Thanks
Dreamweaver do not have the capability built in to natively work with zipped or gzipped files. After you pull down a file from your server, you would need to extract the file(s), make your edits, and then re-pack the file(s) to upload them. If you do not have an application locally to do this, I'd suggest: 7-Zip: http://7-zip.org/
A server side solution could also be used, but I guess that you'd have to have a caching mechanism on the sever that would first check if a newer version of a file exists, if it does then gzip it, if not move on to serving the file. Perhaps ask a new question specific to gzip files to serve using the server language of your choice, I'm sure there are a number of solutions out there.