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.
Related
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
I need a help in .htaccess modification.
I have an index.html , contact_us.html, about.html, faq.html (pages)
But I'd need a simple .htaccess rule to Override those .html extension.
Like this, instead of yoursite.com/contact_us.html a user can still access your contact webpage using yoursite.com/contact_us
Even with or
without the .html extension.
They can still get to the same page they meant to access.
Multiviews. Add this to your .htaccess:
Options +Multiviews
This will also let you keep the same URLs if you later decide you'd rather be working with index.pl or index.php.
I just started developing web page, hosted by iPage.
I wanted to publish my own index.html instead of what was given.
But, when I actually enter the page, it directs to the previously changed page, which does not exist anymore.
I can access index.html, but only when I manually type in the address as epseattle.com/index.html.
How do I fix this?
I have tried fix on htaccess already.
Thanks in advance.
Please try this. Rename the original index.html which was available earlier in your web root to something like this index_1.html. And then try http://www.epseattle.com.
If the above not works, kindly post with your .htaccess file content.
In your .Htaccess file, try this:
DirectoryIndex index.html
Try switching off buffering on the iPage server (you can do this via their site). You will also need to do the same on the browser. Your changes should then be immediately visible. Remember, this is for development only and severely restricts performance of your server.
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
We have a page that has been using a server side include for many years. Recently it stopped working. No changes have been made to the page
<!--#include virtual="..\..\includes\nav.include" -->
Near the bottom of a page called contact.html
The 'nav.include' page simply contains html for a navigation bar. No javascript. No server side scripting. Just html.
Is there some setting somewhere that needs to be set to make SSIs work in the way it is implemented here (including a file with an uncommon extension inside a html file)?
A solution that I discovered yesterday:
I duplicated and renamed all my pages to .php (retained the original html files just in case!)
I have replaced all the {<#include virtual="folder_name/file_name.ext" -->} with
<?php include "folder_name/file_name.ext" ; ?>
with the appropriate number of dots and slashes depending upon where the pages are in my folder hierarchy. ( The {} above is to mark out the code only)
Finally, I renamed the original index.html to some other name so that the index.php is picked up instead of the index.html
This seems to be working out - I am still testing out all the pages and links - a very tedious and time consuming exercise!
INCLUDES SYNTAX:
In a php file use
<?php include "..//folder_name/file_name.ext" ; ?>
In an html file use
<!--#include virtual="../folder_name/file_name.ext" -->
EXPERIMENT WITH NUMBER OF "..." AND NUMBER OF "///" IN THE ABOVE SYNTAX TO GET THE CORRECT COMBINATION!!!!
For me, all my includes are small html files in a folder ABC which is directly under the webroot.
For pages which are under sibling folders of ABC i.e. in other folders directly under webroot, "..//" is the number of dots and slashes that work.
For pages which are directly in the webroot (i.e. not in any folder inside webroot), folder_name/file_name.ext without any dots or slashes has worked.
I haven't had the time to check out the number of dots and dashes required for any other level in the hierarchy!
I hope this helps!
Are you using GoDaddy? They did the same to my site, and I found on their forums someone that said to use include file instead of include virtual.
Just switched over to Godaddy servers and my SSI stopped working. I made a .txt file with the following:
AddHandler server-parsed .html
I uploaded it to the public html folder, then renamed it .htaccess, and everything started working.
I had too many files to convert all the extensions to PHP, so I had to find another answer, if at all possible.
For me, for a little while, exchanging include virtual to include file seemed to help, but then it broke again after a few days. I guess GoDaddy was not finishing monkeying around with the SSI configuration. o_O
The solution, as of tonight, was to convert all relative paths to absolute specification in regards to the site root. For example, I had to convert:
<!--#include virtual="..\..\includes\nav.html" -->
To:
<!--#include virtual="\includes\nav.html" -->
Using this approach, I was able to include HTML files inside other HTML files.
I discovered this on one of my pages that mixed absolute and relative path specification.
HTH
I've been seeing this problem frequently on my GoDaddy hosted site. I have to go into the Server configuration page, disable SSI, save the settings, then re-enable SSI and check "Use SSI on .HTM and .HTML files) and it starts working again.
The problem is on GoDaddy's side. For some reason, it's forgetting that it needs to parse SSI in files, until you turn off and turn on that option. Their Tier-2 support only suggested using Virtual instead of File on the Include command... which is preposterous, since not only does that not change a thing, the SSI includes work just fine most of the time... until it doesn't.
I'm also updating old .html pages to .php and replacing some of the with php include statements on all pages when some of the pages displayed [an error occurred while processing this directive].
The pages displaying the error also referenced an old .ssi file that wasn't even in the directory it pointed to. I deleted the old includes code to the non-existent .ssi file in those pages, and that fixed the error.
This error occurs when you have in your code html documentation like this
<!--#My awesome documentatacion-->
to fix it remove the #, like this
<!-- My awesome documentatacion-->