Apache Server not serving SVGs - apache

What settings do I need to set in order to make Apache serve SVGs?
What I found:
These questions document the use of .htaccess to serve the SVGs with the correct MIME type "image/svg+xml" SVG images not displaying on certain web servers / https://mid.as/kb/00134/configuring-server-to-handle-svg-images / https://davidwalsh.name/serve-svg-image
This question handles the Requested URL not found
None of these helped resolve this issue.
Files:
.htaccess:
AllowOverride All
RewriteEngine on
AddType image/svg+xml svg
Folder structure:
Result:
Other:
Different files like .png work. I also tested it with Node (npx http-server) which worked.

AFAICR any recent version of Apache should have the SVG MIME type already configured. You shouldn't have to do it yourself unless you are running a very old version.
Anyway, a misconfigured MIME type wouldn't casue a 404. I think something else must be going on.
If you haven't already, try looking at the Network tab in your browser dev tools, and the Apache access log to check whether you are actually fetching the URL you think you are. And check that the file permissions are set correctly. Does the file have the correct owner, group, and permissions to be accessed by apache?

Related

How to configure Apache 2.4 to use 'content negotiation' in order to serve webp images?

In my HTML file there are several <img src="images/<filename>.jpeg">
The directory "images" holds these files:
<filename>.jpeg
as well as
<filename>.webp
and
<filename>.jpeg.webp
The latter two are identical webp versions of the jpeg file.
Now I want to configure Apache 2.4 on Oracle Linux 8.6 for 'content negotiation'. I am expecting that Apache returns a .webp file instead of the requested .jpeg file, if the browser supports .webp. I don't want to use the HTML <picture> tag or 'srcset' for several reasons, but leave the code untouched.
I have found several promissing configuration examples for nginx, but unfortunatly only litte on Apache:
https://gist.github.com/sergejmueller/5500879
https://stackoverflow.com/a/58857260/4335480
These two links outline 'rewrites' that are to go to the .htaccess file in the /images directory. I tried them both as '.htaccess' in the 'image' directory and it didn't work. I also put them directly in the httpd.conf and it didn't work either. And I tried these lines in the root directory's .htaccess
'AllowOverride All' is included in all section. Even the 'images' directory is explicitly listed.
In Chrome Dev Tools I verified that the request headers include 'image/webp'.
Probably not necessary: In my despair I have disabled nosniff on the Apache server and verified in the response header that it isn't set.
Whatever I try, the server only returns the jpeg file. I can verify this not only by the file name but also by the content-length field in the response header.
So what can I do to have Apache serve avif, webp and (fall back) jpeg in that order, whenever a jpeg file is requested?
Found the error myself. Note to self: don't just copy code snippets to use them. Read and understand them to find errors or identify necessary adaptions.
Vincent Orback's code is often cited for this problem, so I blindly trusted and used it: https://github.com/vincentorback/WebP-images-with-htaccess
It contains the following line:
RewriteCond %{DOCUMENT_ROOT}/$1.webp -f
The outcome is that .webp images are only searched for in the web server root directory. On my site, images are in a subdirectory called 'images'.
Trying to load an image in the browser would fail (deliver the jpeg, not the webp version):
https://<my domain>/images/<image name>.jpeg
But after altering above line to
RewriteCond %{DOCUMENT_ROOT}/images/$1.webp -f
eventually everything worked!
All the other things were unnecessary. You only need one AllowOverride All before the virtual host containers for <Directory / > and all servers and subdirectories would have .htaccess enabled, if present. For this problem, only one .htaccess in the image subdir was necessary, none in the root and no special httpd.conf entries. I turned nosniff on again. The alternativ .webp files just need the extention .webp, not .jpeg.webp

PDF not opening correctly on web browser for files on remote folder

I'm using a Debian EC2 instance running a Apache2 server (from the open semantic search package).
When I try to open a pdf file in the web browser (inline?), it opens a modified version of it when the file is located on a remote folder but not when the file is located locally.
I saw recommendation (http://www.devside.net/wamp-server/forcing-a-pdf-or-doc-to-open-in-browser-rather-than-downloading) to modify the Apache configuration file to include:
<LocationMatch "\.(?i:pdf)$">
ForceType application/pdf
Header set Content-Disposition inline
</LocationMatch>
I tried adding it to /etc/apache2/apache2.conf
But when I restart the apache server, I get the following error message:
apachectl[16425]: AH00526: Syntax error on line 207 of /etc/apache2/apache2.conf:
apachectl[16425]: Invalid command 'Header', perhaps misspelled or defined by a module not included in the server configuration
My questions are:
Which Apache configuration file should I modify?
Is this modification going to open the pdf file in the web browser inline without downloading / modifying the pdf file when coming from a remote folder?
Thanks!
Yoann
I suspect that it isn't the PDF that is getting corrupted, but the images inside of it.
Some time ago, some server admins were having problems with images getting corrupted by apache2. See for example serverfault and drupalQuestion.
The proposed solution is to change a couple of settings in the apache2 config file. I suspect memory mapping is the issue, which can be turned off by adding the following command to apache2.conf:
EnableMMAP Off
I hope this helps!

URL without file extension working without mod_rewrite

On my server, when I access the file http://example.com/file.php with the URL http://example.com/file, it still displays the correct file, although I have no .htaccess with any URL rewriting.
Can I rely on this to work across all (current) browsers?
You probably have mod_negotiation / Options +MultiViews in your httpd configuration. The kind of negotiation you describe shouldn't have any browser dependency.

Apache 2.4 set mime type of file without extension

I have upgraded from Apache 2.2 to 2.4 on a RedHat 6.4 server and came across an issue with mime types.
Apache has a DefaultType Directive. In Apache 2.2 I set this to "text/plain". I have a webpage that lists all files in a given directory and the user can click to view the files. This directory contains all types of different file extensions and some files with no extensions. When a file was clicked, it would open up in a new window nicely formatted. There is not any code doing this. It is strictly the browser opening the file and deciding what to do based on its content type.
This directive has been disabled in Apache 2.4. The Apache documentation website instructs the user to to use the mime.types configuration file and the AddType Directive to configure media types.
My question is how do I assign the "text/plain" mime type to files with no extension? In Apache 2.2 those files would be given the "text/plain" content type by default through the DefaultType Directive. In Apache 2.4 I cannot figure out how to do this since I can't use this directive anymore. I do not want to use the ForceType Directive because it would override other already defined mime types.
I could create a php wrapper that loads the file and assign a content type but I'd prefer to keep the logic within apache where all other mime type definitions are located.
Any help would be appreciated. If additional information is needed please let me know.
Extensionless files only
This solution affects only extensionless, statically served files: (credit Eugene Kerner)
<FilesMatch "^[^.]+$">
ForceType text/plain
</FilesMatch>
Any unknown content
This one affects any response that would otherwise be transmitted without a Content-Type header. In other words, it mimics the behaviour of the old DefaultType directive:
Header set Content-Type "text/plain" "expr=-z %{CONTENT_TYPE}"
It should be possible to use setifempty here instead of the -z expression. But it fails and overwrites the header in every response, empty or not. I don’t know why. Eric Covener says it’s because the Content-Type header isn’t added “until the very last second”.

pages are displaying plain text instead of html

I am hosting multiple sites on the same server and using a http-vhosts file to specify virtual host info for them. It is working great. The problem is I changed in Movable Type the way entries are created. I want them to not have file extension. So it is currently domain.com/entry/15 instead of domain.com/entry/15.html. Because I took out the .html I'm assuming apache doesn't know what to do so it is spitting out the page as plain text. How can I fix this? I added in a virtualhost block:
DefaultType text/html
I also added that in the httpd.conf hoping it would fix it globally for all my sites. I restarted apache and still the same problem. Any ideas?
Is it possible that this is a content negotiation problem? In a few cases I've seen Apache try to determine what sort of file is being requested by looking at the first few bytes of the file being served.
I have seen problems like this be solved by commenting out mod_negotiation in http.conf and restarting. See the mod_negotiation documentation for more details.
I just solved the same issue by disbabling Magic Mime in httpd.conf (some files would display as html and some as text for no apparent reason).
edit /etc/httpd/conf/httpd.conf
Comment the lines for the Mime Magic Module:
MIMEMagicFile /usr/share/magic.mime
MIMEMagicFile conf/magic
Restart Apache and clear your browser cache
source
That seems correct. Care to share one link, or the HTTP headers that are returned for one of those pages? P.S. as well as the whole Apache config block where you placed that directive, for context?
if u create a .htaccess in ur site's root dir,and the .htaccess's content is:
DefaultType text/html
then the issue is fixed imm.