I'm wokring on a small website that I wouldlike to use Less CSS with, but I am having trouble getting the .less file to become available. If I go to the path on the server that the .less file is at through ftp, the file is there in the browser and I can read it. However, tag in the html is bringing me to a 404 page. If I manually type in the location through http it does not work. Why might this be happening?
Requests for static files return 404 error (IIS 6.0)
Im not sure if i understood you correct, but: LESS is not a replacement for CSS. You must generate a CSS-file from your LESS-file to be able to serve it to the browser.
The reason why you cant view it in your browser is because the web server har no MIME-type for LESS-files, and it shouldnt have.
You can however view it through FTP cause its a "normal" text document.
Edit: You can also process the .less-file with javascript, but thats not recommended for production use...
Related
When I check my website URL on Google URL inspection tool it shows that page resources could not be loaded i.e image, stylesheet and script files. However, my website is working perfectly on a live server and the website is not rendered properly by Googlebot smartphone. I have tried everything to remove these errors but nothing helped. I have also checked that these resources are not blocked in robots.txt file.
Screenshot of page resources error
I've been struggling with this for a couple of days now, and finally reached the only solution that has worked for me. In my case, it wasn't a robots.txt problem, as I believe that you've already checked before posting this.
The problem has to do with the number of resources Googlebot is willing to fetch before giving up. If your CSS and JS files are too many, or too big, Googlebot gives up before fetching all of the resources needed to render the page properly.
You can solve it by minifying your files via a server mod, or via plugins like WP Rocket or Autoptimize. If you have too many CSS and JS files and the problem persists after minifying, try combining these files as well by using the same plugins.
I have a flask app running on an apache HTTP server on ubuntu 14.04. Everything works great, but I'm now trying to make things secure and get HTTPS up and running. The content still renders properly when requesting the HTTP URLs, but static CSS files are not loading when changing the prefix to HTTPS.
Some useful details and previous attempts:
I have the CSS files in the usual static/css location.
This answer was helpful, and got javascript rendering properly, but using AddType for CSS isn't working for some reason.
I tried sudo a2enmod mime to make sure that Apache module was enabled, and it was.
I tried forcing the type for css (similar to what was suggested here, but with css instead of js and javascript), but that didn't work either.
I've tried adding the AddType declaration to my configuration file located in /etc/apache/sites-available/FlaskApp.conf (that's where the successful AddType text/javascript .js declaration is located), and I've also tried putting the AddType declaration in a .htaccess file located in the root directory of my FlaskApp, but both attempts were unsuccessful.
Everything loads fine when accessing the site with the http:// prefix, just not the https:// prefix. I've tried accessing it from Chrome and Firefox.
Chrome Response
Looking at the console when loading the page in Chrome is shows the following for all CSS files:
Resource interpreted as Stylesheet but transferred with MIME type application/x-gzip
Looking at the network tab, everything looks similar between the http request and the https request, except that the https request is completely missing the Response Headers section.
When attempting to load just the /static/css/styles.css file in Chrome, it attempts to download the file instead of displaying it in the browser.
Firefox Response
When attempting to load just the /static/css/styles.css file in Firefox, it loads in the browser. However, it's not ascii text but rather jumbled characters as though it's loading a binary file. Here's the console error message in Firefox:
The character encoding of the plain text document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the file needs to be declared in the transfer protocol or file needs to use a byte order mark as an encoding signature.
So my question is, how do I get my HTTPS/Flask/Apache/Ubuntu setup to properly return static css files so that my pages render properly?
This suggestion and this suggestion look promising, but I'm not sure how to make it so that any request that hits /static/css/*.css returns the proper css file with the "Content Type" or "mimetype" set correctly.
I have a PHP application running on a Micrisoft IIS 7 server. The application shows PDF files on an iFrame, which contains user's sensitive data that I wouldn't like to be directly accessed by anyone that knows the file address.
So basically, I'm looking for a way to protect files from direct browser access or download, but still be able to show it on the application's iFrame.
I made some research with Rewrite rules, but since the "HTTP_REFERER" of an iFrame is empty, I couldn't find a good solution
Any suggestions for this?
Thanks in advance
Without seeing any of your code, or how your application works, I can only give suggestions based on how I think your app works.
Rather than showing the files themselves, with links directly to those files, you should consider changing your application so that the PHP reads in the directory, displays the file names (however you want them to appear), with links that go to a download.php page. The download page (after checking whether the user has permission to download the file) then loads the file into memory and serves it out as a response (with appropriate Content-Disposition and Content-Type headers).
Since your PHP application can read files directly within the web directory, you can set up rewrite rules to prevent accessing those files from the web; that way, the files can only be accessed by the PHP application, which doesn't rely on rewrite rules to access the drive.
This is how places like Source Forge can display an advertisement with a countdown that your file download will begin in 5 seconds.
Is there a setting for apache or .htaccess to not open images in browser, but instead force the user to download them to their computer to open e.g. when he navigates to http://site.com/image.jpg this will make him download the file. The only time I want images loaded in the browser is when they're embedded in a HTML page. e.g. http://site.com/mypage.html
If it is not possible then can we at least just block it completely if they go to http://site.com/image.jpg, they will get error 403 or something for any file other than html and php?
There would be a bit of a performance overhead, but you could make a page (php or whatever language) that all it does it pull up images from a directory that otherwise isn't web accessable. You could then make all image links go to that page and make them still look like image urls using rewrites.
Page: /images/25.jpg => /images.php?id=25&type=jpg or something similar
Note sure exactly what you are trying but might want to read this:
http://michael.theirwinfamily.net/articles/csshtml/protecting-images-using-php-and-htaccess
I just installed MediaWiki on a website and I am having some problems.
Whenever I go to "www.something.com/wikidir" the server gives me the PHP index file as an unnamed download instead of displaying it.
However, if I go to "www.something.com/wikidir/index.php" everything works as expected.
I'm not familiar with Apache and was wondering if someone could tell me how to fix this or point me in the right direction?
I'm using a LAMP stack and Mediawiki 1.7.1 (old I know).
In my .htacces file I have:
AddType application/x-httpd-php5 .php
Sounds like Apache (or PHP?) is serving the page as an application/octet-stream. You can check this by looking at the response headers on the non-index.php page. Firefox can do this using the Web Developer Toolbar > Information > View Response Headers. Look for "Content-Type"
Or, Does the non-index.php link work in IE? Does it go straight to download in Firefox (or another browser)? If the answer is yes, that's the problem.
How to fix it is more complex because there could be a bunch of different things that are causing this. My guess is that's it's an Apache config issue.
Edit
Check your .htaccess file. Make sure it's readable by Apache. I bet that's the issue.