Firefox doesn't understand svg on remote server - apache

I've got a curious problem where FireFox (and IE9, I think) can display a local html file which embeds an svg, but it can't display exactly the same file when it's on a remote server. Any ideas much appreciated.
The setup is that I have a test directory which contains index.html, an svg file, and a js file. When I point any browser at index.html it correctly displays the embedded svg. However, when when I upload this test directory to a remote server, then:
1 - Opera, Safari, and Chrome correctly display the svg
2 - FireFox complains that it needs a plugin for the svg
3 - IE9 displays nothing.
Something is different about the remote setup, but I have no idea what. My suspicion is that this is an interaction of some sort with Apache (when I view index.html locally I'm not using Apache, of course - the browser is directly viewing the file).
Any ideas? Thanks.

Make sure the remote server sends the appropriate MIME type "image/svg+xml".

I run to this issue aswell on my remote server.
Adding this to .htaccess file solved my problem.
AddType image/svg+xml svg
AddType image/svg+xml svgz
For more information see SVG MIME TYPE

Related

An object within an iframe has a src that is an svg file, type image/svg+xml. It renders as text on remote server, but as image on local server. Why?

I have a web page that contains an iframe, and within the iframe is an object with a src= attribute of an svg file that displays properly when I serve the page from localhost (running apache 2.4 on Windows 10). But when I serve the same page from an Amazon Linux instance, also running apache 2.4, the svg file for the object is rendered as text. I'm quite sure the pages are the same, because the content of the htdocs tree is managed by git, and I make changes on the Windows 10 PC and commit them, then push and pull them onto the Amazon Linux machine.
I've attached two screenshots of what I see in Chrome Developer Tools for the same page on the two systems. As you can see, on the PC, the <object> expands into a #document followed by an <svg>. But on Linux, the <object> expands into a #document followed by <html>, with the source code of the svg file wrapped in a <pre> tag within the <body>. How is this even possible?? I'm using the same Chrome bowser instance, the only difference is which server is serving the page.
I offered Danny '365CSI' Engelman the opportunity to post his comment as an answer, but he didn't take it, so I'll post the answer myself. My problem was that the Apache server I was using had a rather old mime.types file in the etc directory of its configuration (I was using xampp, which has its own etc directory packaged with it). That old version of mime.types did not have an entry for .svg files. Replacing it with a newer version from svn.apache.org, and restarting the server, solved the problem.
I found this quite surprising, since my <object> element had an attribute of type=image/svg+xml, which is the same as the type given in the updated mime.types file. Surprising because the file command on the server recognized the file as having that mime type. And so the lack of an entry for .svg in the mime.types file actually caused apache to ignore the type attribute on the object element, and render the content of the object as text!

IE and Edge are ignoring application/octet-stream MIME Type

Recently I've created a subdomain for downloads and I want the browser to download files instead of viewing it. For this I've added the following line into the .htaccess file:
AddType application/octet-stream .txt .png .jpg .jpeg .gif .exe .zip .rar .gz .sh .bat .doc .docx
On Firefox and Google Chrome it works but both Microsoft browser - Internet Explorer and Microsoft Edge are ignoring the MIME-Type and viewing them instead. How I also can force them to also download the files?
I can see that you had added all the file types in single line. So you can try to add them in separate line to check whether it solves your issue or not.
Based on my search, I find that IE can work with code below. So you can also make a test with it.
# Force PDF Download instead of display
<FilesMatch "\.pdf$">
ForceType applicaton/octet-stream
Header set Content-Disposition attachment
</FilesMatch>
## End Force PDF Download instead of display
Reference:
Forcing a file to download in a browser via htaccess
If you are using PHP than you can try to refer approach below.
PHP allows you to change the HTTP headers of files that you’re writing, so that you can force a file to be downloaded that normally the browser would load in the same window. This is perfect for files like PDFs, document files, images, and video that you want your customers to download rather than read online. Using PHP you can take advantage of the PHP built-in readfile function:
$file_url = 'http://www.example.com/file.pdf';
header('Content-Type: application/octet-stream');
header("Content-Transfer-Encoding: Binary");
header("Content-disposition: attachment; filename=\"" . basename($file_url) . "\"");
readfile($file_url);
exit();
Reference:
(1) Force Files to Download and Not Open in Browser Using Apache or PHP
(2) Force save files all browsers - not open in browser window

Safari ignores cache control

I built an image resize script to resize the requested image and return it with PHP. However I would like to cache the requested images.
I tried to built some .htaccess rules and realized cache-control is not working in safari for me. Safari caches .css files, etc. automatically but does not cache images. I do not have any website specific developer tools active, and tested this in a blank environment with an extra subdomain with only a .htaccess and a .jpeg file.
My .htaccess code looks like:
Header set Cache-Control "max-age=10800,private"
With nothing else in it which should force all files to be cached for 3 hours. With Chrome however this works as expected and caches the files. Server returns a http header 304 telling the client to load the file from the cache.
Taking a look at the safari file informations in the developer menu, I can see the Cache-Control settings are received well (Cache-Control: max-age=10800,private) but on each reload safari shows a http 200 response without any cached files and loads the image again.
Are there any known issues with safari cache control? I searched the web but did not find anything and my web hosting provider told me caching is nothing browser specific on server side.

How do I return css files with response headers using a flask app running on Apache with HTTPS?

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.

Why can I view .less file through ftp, but not http?

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...