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.
Related
The problem: I am using html generated from one site that is being pushed to another site (different domains). All is working well except the font (used mainly for icons) is not showing up. I am receiving a CORS error as described further below.
I have added the following code to my .htaccess file on the site where the fonts are stored that allows fonts to be access across any domain:
<FilesMatch ".(eot|ttf|otf|woff)">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
I checked the header using cUrl:
curl -I https://mywebsite.com/fonts/flatpack.woff?tzy7cr
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 23 Jun 2017 18:33:58 GMT
Content-Type: text/plain
Content-Length: 142020
Connection: keep-alive
X-Accel-Version: 0.01
Last-Modified: Fri, 23 Jun 2017 17:49:02 GMT
ETag: "1a474c-22ac4-552a4378235b7"
Accept-Ranges: bytes
X-Powered-By: PleskLin
Access-Control-Allow-Origin: *
The Access Origin response tells me that the font should be readable but I'm still getting this error from the requesting website:
Access to Font at https://mywebsite/fonts/flatpack.woff?tzy7cr' from
origin 'http://anotherwebsite.com' has been blocked by CORS policy: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://anotherwebsite.com' is therefore not allowed
access.
Thoughts or suggestions???
Edit: Here is a live link to a test page that fails to load the icon fonts.
Almost got it right:
Header add Access-Control-Allow-Origin "*"
Header add Access-Control-Allow-Methods: "GET"
You need to add the header not set. I'd also add the method to be sure.
Premium font purchased by some other website can be abused another site. That is the reason of complication at browser level coding. Image will not suffer such issue. Font related CORS is complicated by types of fonts, browsers and bugs. Unless you are using paid origin pull CDN or known font provider (free or paid), it is practical to serve font from own server for the sake of making sure that font loads on all browsers, all devices. It is worthy to read :
official W3 doc about CORS,
Mozilla doc,
MaxCDN's guide,
W3's CSS font doc,
this old bug report
this pull request
There are three options from the above resources for giving you a correct answer. You need to test from webpagetest dot org from different user agents & devices and try to watch the video of screenshot.
One :
SetEnvIf Origin "https?://(.*\.(mozilla|allizom)\.(com|org|net))" CORS=$0
Header set Access-Control-Allow-Origin %{CORS}e env=CORS
<FilesMatch "\.(ttf|woff|eot)$">
Header append vary "Origin"
ExpiresActive On
ExpiresDefault "access plus 1 year"
</FilesMatch>
Two (Single domain, HTTPS) :
<FilesMatch "\.(ttf|otf|eot|woff)$">
SetEnvIf Origin "^http(s)?://(.+\.)?anotherwebsite\.com$" AccessControlAllowOrigin=$0
Header set Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin
</FilesMatch>
Three (Multiple domains) :
<FilesMatch "\.(ttf|otf|eot|woff)$">
<IfModule mod_headers.c>
SetEnvIf Origin "http(s)?://(www\.)?(anotherwebsite.com|cdn.anotherwebsite.com|blahblah.anotherwebsite.com)$" AccessControlAllowOrigin=$0
Header add Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin
</IfModule>
</FilesMatch>
Also make sure that proper MIME types are present :
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
Make sure to run Apache configtest before restarting. You may need to activate some module.
I do not want to take credit for the answer, but this worked for me, thanks to this guy:
https://crunchify.com/how-to-fix-access-control-allow-origin-issue-for-your-https-enabled-wordpress-site-and-maxcdn/
Add below lines to .htaccess file and put it inside your (font) folder:
<ifmodule mod_headers.c="">
SetEnvIf Origin "^(.*\.domain\.com)$" ORIGIN_SUB_DOMAIN=$1
Header set Access-Control-Allow-Origin "%{ORIGIN_SUB_DOMAIN}e" env=ORIGIN_SUB_DOMAIN
Header set Access-Control-Allow-Methods: "*"
Header set Access-Control-Allow-Headers: "Origin, X-Requested-With, Content-Type, Accept, Authorization"
</ifmodule>
I have downloaded some .mp4 files from shutterstock to use them in my website project.
Everything works perfect on localhost, i can play the movies like localhost/example.mp4 on every browser. I uploaded the files on my server, but now, it won`t play with Google Chrome (myserver.com/example.mp4), but will play with other browsers. This is very strange.
Anyone have any explanation ?
I checked the mime types in my cPanel account and all are ok, also i added the next code into htaccess but still doesn`t work.
AddType video/ogg .ogv
AddType video/mp4 .mp4
AddType video/mp4 .mov
AddType video/webm .webm
and
<FilesMatch mp4>
Satisfy any
order allow,deny
allow from all
</FilesMatch>
What should be the issue? Is a file issue or an issue from the server? Cues from localhost it will open in Google Chrome.
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>
Google page speed tool tells me this: "Compressing resources with gzip or deflate can reduce the number of bytes sent over the network"
and of course lists all my .js and .css files.
Researching here eventually led me to this question:
How to Specify "Vary: Accept-Encoding" header in .htaccess
Which seems to say that for just .js and .css files all I would need to do is this:
<IfModule mod_deflate.c>
#The following line is enough for .js and .css
AddOutputFilter DEFLATE js css
</IfModule>
<IfModule mod_headers.c>
<FilesMatch "\.(js|css)$">
Header append Vary: Accept-Encoding
</FilesMatch>
</IfModule>
Can someone confirm that this is the current "best practice" for this objective and that it is failsafe, assuming the user is on a modern browser (e.g. not < IE7 for example)
Thanks!
Google PageSpeed says I should "Specify a Vary: Accept-Encoding header" for JS and CSS. How do I do this in .htaccess?
I guess it's meant that you enable gzip compression for your css and js files, because that will enable the client to receive both gzip-encoded content and a plain content.
This is how to do it in apache2:
<IfModule mod_deflate.c>
#The following line is enough for .js and .css
AddOutputFilter DEFLATE js css
#The following line also enables compression by file content type, for the following list of Content-Type:s
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml
#The following lines are to avoid bugs with some browsers
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
</IfModule>
And here's how to add the Vary Accept-Encoding header: [src]
<IfModule mod_headers.c>
<FilesMatch "\.(js|css|xml|gz)$">
Header append Vary: Accept-Encoding
</FilesMatch>
</IfModule>
The Vary: header tells the that the content served for this url will vary according to the value of a certain request header. Here it says that it will serve different content for clients who say they Accept-Encoding: gzip, deflate (a request header), than the content served to clients that do not send this header. The main advantage of this, AFAIK, is to let intermediate caching proxies know they need to have two different versions of the same url because of such change.
I'm afraid Aularon didn't provide enough steps to complete the process. With a little trial and error, I was able to successfully enable Gzipping on my dedicated WHM server.
Below are the steps:
Run EasyApache within WHM, select Deflate within the Exhaustive Options list, and rebuild the server.
Once done, goto Services Configuration >> Apache Configuration >> Include Editor >> Post VirtualHost Include, select All Versions, and then paste the mod_headers.c and mod_headers.c code (listed above in Aularon's post) on top of on another within the input field.
Once saved, I was seeing a 75.36% data savings on average! You can run a before and after test by using this HTTP Compression tool to see your own results: http://www.whatsmyip.org/http_compression/
Hope this works for you all!
Matt
To gzip up your font files as well!
add "x-font/otf x-font/ttf x-font/eot"
as in:
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml x-font/otf x-font/ttf x-font/eot
This was driving me crazy, but it seems that aularon's edit was missing the colon after "Vary". So changing "Vary Accept-Encoding" to "Vary: Accept-Encoding" fixed the issue for me.
I would have commented below the post, but it doesn't seem like it will let me.
Anyhow, I hope this saves someone the same trouble I was having.
Many hours spent to clarify what was that. Please, read this post to get the advanced .HTACCESS codes and learn what they do.
You can use:
Header append Vary "Accept-Encoding"
#or
Header set Vary "Accept-Encoding"
if anyone needs this for NGINX configuration file here is the snippet:
location ~* \.(js|css|xml|gz)$ {
add_header Vary "Accept-Encoding";
(... other headers or rules ...)
}
No need to specify or even check if the file is/has compressed,
you can send it to every file, On every request.
It tells downstream proxies how to match future request headers to decide
whether the cached response can be used rather than requesting a fresh
one from the origin server.
<ifModule mod_headers.c>
Header unset Vary
Header set Vary "Accept-Encoding, X-HTTP-Method-Override, X-Forwarded-For, Remote-Address, X-Real-IP, X-Forwarded-Proto, X-Forwarded-Host, X-Forwarded-Port, X-Forwarded-Server"
</ifModule>
the unset is to fix some bugs in older GoDaddy hosting, optionally.