After making frequent edits to my stylesheet on WordPress Avada child theme (either through the custom CSS editor in Avada or SiteOrigin CSS plugin) the website will randomly lose access to the stylesheet. Sometimes a couple of pages, sometimes the whole site is loaded without formatting
I have found that Chrome is throwing the
Refused to apply style from <path> because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled
However, I do not believe that it is caused by the stylesheet starting with a comment as mentioned in other posts related to this error.
When I go to my file manager and follow the path shown in the error, the .min.css file that it is pointing to is not there. I have solved the issue by downloading the most recently edited stylesheet (there are usually 2 or 3) and renaming it to the file that Chrome inspector shows in the error.
Expected result: site automatically updates the path to the latest .min.css file
Actual result: the site will not point to the correct file, but only occasionally/randomly.
Two main questions:
Is there something I am doing incorrectly to cause this (editing too fast, editing through plugins, etc.)
Once this error occurs, how can I tell my site to go look at the latest style sheet?
Strict MIME type checking is a security feature that can be activated by sending the HTTP Header X-Content-Type-Options: nosniff to the client, see
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options .
Clients that respect this header must only rely on the MIME type sent by the server, so you have to make sure that CSS files are served with the correct header, which seems not to be the case with some wordpress setups, probably by a plugin that optimizes style and script files.
If you able to edit your server's .htaccess file(assuming a typical wordpress installation on an Apache webserver), you could try add a Set-Header directive like:
AddType text/css .css
Related
I have a simple reverse proxy server using Apache 2.4.20 which gets HTML files from an internal Apache web server. The page fetching and URL rewriting is working fine, but there is a problem occurring.
After any webpage is passed through the proxy, three things are incorrect: the contents of the head tag appears in the body, the head tag is missing and a mysterious ">" character in a "p" tag is added at the top of the body tag.
This extra <p>></p> code suggests to me something wrong with the detection of a HTML tag (it could be part of <head>). Also, even without content in the head tag, the body tag still begins with that weird code.
Proxied content - viewed in developer tools, Google Chrome browser:
Proxied content - original source of fetched file:
Original HTML file - opened directly from internal server filesystem:
Proxy server configuration file - section about transfer and ProxyHTML:
I know the original server is working correctly so this isn't causing the problem.
Here's a screenshot of the HTML file viewed directly from the original server in a browser (on the proxy server device), along with source code shown in Chrome Developer Tools:
Update: As expected, mod_proxy_html is the main cause of my problem (turning it off left the original file). However, this isn't a solution for me because I need the tool to rewrite relative URL references in the proxied documents. I read the documentation page but it didn't describe any features that undoubtedly caused my problem.
List of mod_proxy_html directives from the documentation which I think aren't relevant, some tested: ProxyHTMLBufSize, ProxyHTMLCharsetOut, ProxyHTMLDocType, ProxyHTMLEnable, ProxyHTMLEvents, ProxyHTMLExtended (default off), ProxyHTMLFixups (tried from suggestion), ProxyHTMLInterp, ProxyHTMLLinks, ProxyHTMLMeta (default off), ProxyHTMLStripComments, ProxyHTMLURLMap.
I had the same issue. However, on the same machine, other sites that used the same reverse-proxy worked fine, even when they have exactly the same config, but different URL. I could not understand... except after I have noticed that the files that had problem had the BOM signature at the beginning of the file!
This caused the ProxyHTML to be confused so much that it had removed the <head> and </head> tags.
After I have removed the BOM using the dos2unix utility, files were shown properly.
Your post gave me extra motivation for fighting this. Thanks.
you are using mod_proxy_html
This mod will try to affect HTML resources proxied through depending on the directives. My advice would be to remove the ProxyHTML directives and see what comes back. If it is unaffected then you know its something to do with mod_proxy_html.
Then look at adding this directive below the ProxyHTMLEnable
ProxyHTMLFixups off
Your problem is the document type definition
<!DOCTYPE html/>
the tag should not be closed. It should look like this:
<!DOCTYPE html>
mod_proxy_html tries to fix what it sees as an extra > character by wrapping it in paragraph.
I apologize in advance for the generic examples of this since the issue is with a proprietary corporate system.
I support a web app that allows for edits to a secondary CSS file in order to style the page (within the limits of the application). I'm trying to apply a non-standard font that is used company wide but I do not have access to edit the HTML or header of the site, only the CSS. I tried declaring the font-family in the main CSS while referencing the actual font file URLs (since they are used on our corporate site) but they never actually loaded.
I then took the same font-family snippet and created a separate CSS file for just the font declaration and changed the URL to point to the actual files in the relative path (ex: url('fonts/DINWeb.woff') ). I moved this fonts.css file along with the reference font files (eot, ttf,and woff versions) to a public Dropbox folder for testing. I was able to get everything working by simply importing the fonts.css file using the line of code below (URL modified) at the top of my application's CSS.
#import url('https://dl.dropboxusercontent.com/.../fonts.css');
The problem is that the Dropbox solution was just for temporary testing purposes. Once I confirmed everything worked as expected, I moved the exact folder structure to an external hosting location that is approved for use. When I update my import code in the CSS to the new URL, the font does not load. I can access the CSS file and the font files from my browser without any issue so I don't understand why the web app fails to load it. I also have images hosted in this same hosting location that pull into the web app without an issue, it's only the font that has issues. The files work when hosted on Dropbox but not the other source. I've also double checked the references for the URL and they are still correct since the folder structure never changed.
Any suggestions would be GREATLY appreciated. Ideally I would like to just reference the corporate URLs directly in the web app's CSS like I initially tried. If that will not be possible, I need it to work with the externally hosted files since Dropbox cannot be used as the permanent solution.
Basically you cannot load from one domain resources hosted in other domain, unless the second host says that you can. See CORS
You can solve it by moving everything to the same domain (or forcing the user to be always in certain domain) or by adding the Access-Control-Allow-Origin header to the responses.
You can achieve this last thing if you can edit an .htaccess file in the server. Add:
Header set Access-Control-Allow-Origin "*"
Or replace the * with the domain from which you'll be making the requests.
Yes, a subdomain is a different domain (abc.com, www.abc.com and dl.abc.com are not the same).
Browsers (Chrome and Safari) Try to download this html file when opened. It is only on that link that it tries to download it. Also note that internet explorer opens it without a problem.
The one thing that I think is causing this may be wordpress or some plugin within wordpress but it seems unlikely since no wordpress is used in that page.
Contact html code
Likely an incorrect mime type in your .htaccess file. I suggest going into it and looking for any unwanted lines similar to the below and removing them.
AddHandler application/ etc.
and also ensure your type is set as follows:
AddType text/html .html
In order to open .htaccess in cPanel:
Click File Manager and make sure to tick Show Hidden Files (dotfiles) before clicking Go. Then the .htaccess should show up the location where wp (wp-admin, wp-content, wp-includes) is installed.
One possible cause is that there is a problem with your server configuration that is giving the visiting browser the wrong mime type.
The correct mime type for html is: text/html
The mime type that your server is sending is: application/x-httpd-php
You appear to be running Apache. As a result there are two possible files that could be causing this, either in .htaccess or in one of Apaches configuration files.
Try adding the text below to a .htaccess file in your directory, or look for a mention of application/x-httpd-php
AddType text/html .html
I had to add the following at it worked:
AddHandler application/x-httpd-php .php
I've had this issue a couple of times. The problem for me was the web server was automatically handling PHP requests outside of the .htaccess file. For some reason, changing settings in WordPress would sometimes cause a change in the .htaccess file, adding a handler for PHP. This would cause the server to burp at every PHP request thereafter and attempt to serve the file instead of handle it.
The solution, then, was to manually remove the handler that was automatically added to the .htaccess file (and leave a comment for myself so I wouldn't pull my hair out every time!)
Had same thing happen to me. I know this sounds funny but check to make sure none of the keys on your keyboard are stuck. i.e) ALT key , etc. if not. Try hooking up a new keyboard and then browse.
Everything works fine locally but when the stylesheets are uploaded to the server, the styles aren't being applied to the page. Chrome shows this error:
Resource interpreted as Stylesheet but transferred with MIME type text/x-asm
If I open the .css files in Chrome inspector and make any change to them there (including trivial changes such as hitting backspace or enter), then the styles are applied to the page and everything works as it should. But replicating this change in the actual stylesheet and re-uploading to the server does not solve the problem.
I validated the CSS using the W3C CSS Validator in hopes of finding something that would cause a parsing error on the server. All files validate but the problem remains.
Answers to similar questions on Stackoverflow point to server configuration. I'm a front-end developer at a large agency and don't have easy access to server configuration. What's more, stylesheets for other sites being served from that server do not incur that error. And when I link the problematic site to a stylesheet from another site, I get the same error. Which makes me think that the problem isn't server configuration or the stylesheet itself, but something else. I'd post more code but my employer's policy prohibits me from doing so.
Is there anything client side which could be causing this error?
If your company is using HTTP-Server-Simple-Static for serving CSS file it might be a server bug: https://rt.cpan.org/Public/Bug/Display.html?id=91321 It looks like the used method to autodetect the mime type sometimes get wrong results. Does it help, if you change the first lines of your CSS?
I had this same problem with Firefox telling me the (static) stylesheet was not loaded because the type of the static CSS file was "text/x-asm" instead of "text/css". Server mime types were all correct. Turned out, the stylesheet had tabs instead of spaces for indentation. I converted the tabs to spaces, and it was served and loaded properly.
Linux-based Webservers often use a program called file to determine the mimetype of a file to be downloaded.
file appears to have a problem with css if any of your class names start with any of the following:
.asciiz
.byte
.even
.globl
.text
.file
.type
To resolve the problem, rename the offending class.
Reference: https://serverfault.com/questions/597777/how-to-correct-the-mime-type-from-being-recognized-as-text-x-asm-to-text-css
from Dive into HTML5: Cache Manifest: Fallback section
CACHE MANIFEST
FALLBACK:
/ /offline.html
NETWORK:
*
i dont understand from the URL given what this block of code exactly does. does the fallback section mean when anything is not found, show the offline.html page
then network: * all resources will be cached? it says also
It uses common CSS, JavaScript, and
images on each page. Each of these
resources would need to be listed
explicitly in the CACHE
this seems to conflict to network: * where it seems to say cache everything?
There are three types of headings in a cache manifest, CACHE, NETWORK and FALLBACK. Anything that is not under a heading is implicitly set under CACHE. An explanation of each section:
CACHE: Files under this heading will be cached.
NETWORK: Files under this heading require an internet connection and so will be NOT be cached.
FALLBACK: Files matched by patterns under this heading (Such as the pattern "/", which matches all files) and have not been cached, will have a fallback file shown instead.
With regards to the block of code from Dive into HTML 5, there is an explanation of the "NETWORK: *" part just under it:
It means that, while you’re browsing
this hypothetical offline-enabled
Wikipedia online, your browser will
fetch images and videos and other
embedded resources normally, even if
they are on a different domain. (This
is common in large websites, even if
they aren’t part of an offline web
application. HTML pages are generated
and served locally, while images and
videos are served from a CDN on
another domain.) Without this wildcard
flag, our hypothetical offline-enabled
Wikipedia would behave strangely when
you were online — specifically, it
wouldn’t load any externally-hosted
images or videos!
The following quote:
It uses common CSS, JavaScript, and
images on each page. Each of these
resources would need to be listed
explicitly in the CACHE
means that you must include all necessary CSS, Javascript and image files in the manifest under the CACHE heading. It does not conflict with 'NETWORK: *' because the NETWORK heading does NOT mean 'cache everything'. It actually means the opposite: that everything under the NETWORK heading requires an internet connection and should not be cached.
I have found out more useful stuff about FALLBACK:
After a bit of experimenting, I tried various things including whether files in FALLBACK: should appear in the CACHE or NETWORK sections at all. The answer seems to be no.
As an example...
FALLBACK:
sign-up-portrait.png offline-portrait-1.png
sign-up-landscape.png offline-landscape-1.png
I specified this in one of my micro sites recently. The intention is to show the sign-up- png files when online and the offline- png files when offline. This works well. In particular the files on the left side of each line are implicitly as if they were in the NETWORK section, the site will always try to get them online. They must not be added to the NETWORK section as well, otherwise it seems to override what's in FALLBACK.
Plus, happily, the files on the right are implicitly as if added in the CACHE: section so even if they are not used at first, they are cached on first load without having to explicitly add them to CACHE: although you can add them there too if you want. It makes no difference.
For this configuration, looking at the webserver logs, I see that each time the page is refreshed, apache logs a 304 against the manifest file and against the sign-up- png file that's required for that version of the page (there's a CSS media selector determining which, based on page size). So it's correctly always checking for the sign-up- png files as well as the usual manifest checking, which is exactly what I want.
For the sake of being thorough, I tried to see if the root file needs to be in the CACHE: section too. It turns out it doesn't! If your top level file is index.html and it has the manifest file specified in its html tag then the manifest file need not contain index.html anywhere, it's implicitly cached.
I am curious how far the app cache can extend. Can you include other html files that are linked to or in iframes? Or do those all need to have their own manifest files that are separate? Anyone care to comment?
A side comment about format, don't make the mistake I did, which is to put in...
NETWORK
file1.js
Missing the colon causes it to totally break, thinking that NETWORK is a resource in its own right.
It must be...
NETWORK:
file1.js