If I configure Apache to serve /favicon.ico as MIME type image/vnd.microsoft.icon, instead of image/x-icon, will it break on any browsers? Wikipedia's favicon article indicates that image/vnd.microsoft.icon is the "correct" mime type, but that doesn't help if it means some users won't see it.
I need to support IE6+, as well as modern browsers (FF/Chrome/Opera/Safari).
Off the top of my head, image/vnd.microsoft.icon will work only if the image actually is a real ICO file, while image/x-icon is less fussy, and will also work for bitmaps and GIF images. (Non-ICO files with the .ico file extension are, I believe, quite common.)
Google serve /favicon.ico as image/x-icon, and I'd guess they know what they're talking about (or at least, what's compatible).
Related
I am working on a site that I've inherited, and I'm looking at the .htaccess file. Truth be told I'm really NOT familiar with writing custom .htaccess rules, so I was wondering if someone can explain to me what is going on in this code snippet?
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{DOCUMENT_ROOT}/$1.webp -f
RewriteRule (.+)\.(jpe?g|png)$ $1.webp [T=image/webp,E=accept:1]
</IfModule>
After doing some googling, I'm pretty sure its taking any image that's served up and returning with webp on the end instead of its original extension?
I believe the intent of the code is to fool pagespeed insights so that it doesn't complain about serving next gen image formats.
I was just wondering if someone can give me a full break down on exactly what is going on and how it works?
Also, I've noticed that when I do change image sizes on the site (for optimisation purposes), pagespeed doesn't register the changes whilst this code is present in the htaccess, like its contributing to some sort of image cache? If I remove this snippet, pagespeed detects the new optimised images?
i'm pretty sure its taking any image thats served up and returning with webp on the end instead of its original extension?
Basically, yes. (Although, it's not a "redirect".)
More specifically... (providing mod_rewrite is enabled - checked by the outer <IfModule mod_rewrite.c> container):
RewriteRule (.+)\.(jpe?g|png)$ - For every URL-path that matches the regex (.+)\.(jpe?g|png)$. In other words, any URL that ends in .jpg, .jpeg or .png.
RewriteCond %{HTTP_ACCEPT} image/webp - And the Accept HTTP request header contains the string image/webp. In other words the user-agent accepts webp images.
RewriteCond %{DOCUMENT_ROOT}/$1.webp -f - And the corresponding .webp image exists in the same place as the requested file. eg. Request /foo/bar/baz.jpg and /foo/bar/baz.webp exists.
RewriteRule -------- $1.webp - Then internally rewrite the request to the .webp image (eg. foo/bar/baz.webp). Note that this is not a "redirect", the user-agent still sees the original .jpg (or .png) filename. Also...
T=image/webp - Sets the Content-Type header to image/webp. (Overriding the image/jpeg or image/png value that would otherwise be sent.)
E=accept:1 - Sets the environment variable accept to 1. (This can then be used by your application.)
I believe the intent of the code is to fool pagespeed insights so that it doesnt complain about serving next gen image formats.
I don't think the intent is to necessarily "fool pagespeed insights". (That's a lot of work just to fool a tool!)
However, it does allow graceful degradation... a .jpg is served by default and .webp is served if the user-agent supports it (and it exists!).
Also, i've noticed that when I do change image sizes on the site (for optimisation purposes), pagespeed doesn't register the changes whilst this code is present in the htaccess, like its contributing to some sort of image cache? If I remove this snippet, pagespeed detects the new optimised images?
Are you regenerating the .webp image?
This code only applies when requesting .jpg (or .png) images and the corresponding .webp image exists. Unless you also update the .webp image (or it didn't exist in the first place) then any compliant user-agent will not see a change in your image.
In the future... when everything and everybody supports .webp images then you could safely remove the two RewriteCond directives (and the relatively expensive filesystem check). And save all your images as .webp (no .jpg images exist on your site). The image URL would still be .jpg. These directives allow you to upgrade your images without having to change the URL.
In which case you should also remove the <IfModule mod_rewrite.c> wrapper as your site is now dependent on mod_rewrite doing its thing. The <IfModule> wrapper should only be used if mod_rewrite is optional to your site working "normally".
I read that it's important to specify which file types you want to leverage browser caching with. However, what if you're confident you want a similar time-frame for ALL files to cache, can you just set a general command like this?
.htaccess code:
ExpiresActive On
ExpiresDefault "access 64 days"
That's what I did for my site and it seems to be functioning as I expected (caching everything). Is there anything wrong with doing this instead of specifying each individual file type?
It's very easy to do specific file types without doing a lot of work.
There are some things you might not want to cache like html pages etc. If you update your site, it might not be reflected immediately for some people unless they clear their cache. Most people don' t do that often. Don't be lazy. lol Just do the files that won't change often like images etc. One rule get's 5 extensions and more can be added.
<FilesMatch "\.(gif|jpg|png|js|css)$">
#expires in 1 month
Expires A2592000
</FilesMatch>
In Joomla 3.3, I'm faced with the option to gzip in:
Joomla System Config
Template Options (Meet Gavern)
Plugins/Extensions such as
JCH Optimize
Scriptmerge
And from the server itself, in
.htaccess .
(I'm currently using ## Compress Page Weight
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html
in .htaccess, along with JCH Optimize to do everything but Combine CSS & Minify HTML )
Just a few times, I've come across forums which said if compression's used somewhere else, then turn it off in System Config. However, there isn't just 'one other place' to activate compression - Which leads to this post:
A) Do the compression-instances as mentioned above, all use the same process? / "Is it truly, really, redundant to use JCH Optimize to compress (gzip) something WHILE using DEFLATE in .htaccess?" (Similar to double-compressing a zip file on my mac?)
B) If not truly, really, redundant - What is the difference in these compression-instances? Is there one that's more effective?
C) Is my reasoning correct that 'there should be one instance of each type compression (Compression of CSS/JavaScript/HTML)' ?
D) What is the actual best approach to take in ordering the place where compression-instances should be activated for the site? Like,
"1)HTACCESS->compress only javascript and minimize CSS,2)JCHOPTIMIZE->use only to defer and async Javascript," - Or something like this.
I apologize for all these questions - This is really frustrating, because, one wrong application in the wrong place, can break something very obscure and necessary in your site. Since there are SO many places where these compression instances can be invoked, the possibilities of ineffectiveness/catastrophe seems daunting. (Let's not even get into how JCH Optimize presents like 20 different options) - - - That's why I'm asking for anyone who can at least give a general approach to this problem, and, maybe like an 'Order of Operations' (Please Excuse My Dear Aunt Sally - sort of thing) to effectively streamline a site's gZip/Minification/Defer/Async procedure.
Thanks in advance!
You are right, it is pretty important to only run each of the optimizations/compressions once.
But beware of the articles that warn you about processor overhead of compression, on modern servers it's hardly noticeable.
That said, since most external resources don't change at each request, it's most convenient to compress them once and only check for file modifications when you serve the page. This will save a little overhead.
I use TooManyFiles to join, minify and compress css and js files. It will only compress when there's a new version of the files.
Then I let Joomla do the page compression.
Please note that this is only part of the issue. You want to ensure proper system-page cache are enabled in Joomla (this will save a lot of rendering time) and that you enable browser cache (I use the boilerplate .htaccess for that, works excellent, thanks to Paul Irish).
Source: I make a living optimizing Joomla sites. I am the developer of Too Many Files. Also another extensions of mine, Little Helper, ships with a Joomla version of the boilerplate .htaccess you can install with one click.
I have a simple upload form that allows a file to be uploaded to a folder in the site. I don't want to allow anything but .pdf files to be uploaded. However, I cannot modify the form at all to limit the upload. And I can't use PHP on the back end to limit it either. Javascript is unsecure because a user can turn it off. How can I limit the upload to a .pdf file with .htaccess?
As far as I know, it isn't possible. You could, however, restrict the files being returned, and force their mime type to be application/pdf, so they will be treated like PDFs, even if they aren't. If this was combined with JavaScript, it would help honest users (ex, if someone accidentally selects a .jpg they will get a warning right away), and it will make attacks more difficult.
It seems like the third-party mod_upload might be able to help, though.
To restrict the output types, you could use a .htaccess file similar to this:
# Prevent request to non-.pdf files
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} ! \.pdf$
RewriteRule (.*) $1 [F]
# Tell the browser that this is a PDF
Header set Content-Type application/pdf
# Hint that the browser shouldn't try to auto-detect the content type
Header set X-Content-Type-Options nosniff
(note: I wrote those from memory, so make sure to test them before you trust them…)
I have a folder structure like this /img/products/{product name}/ and then the sub folders hi, low, and thumb.
I want to use htacess to force-download any files in a 'hi' or 'low' subfolder (but not 'thumb').
I was hoping something like this would work:
<FilesMatch "\(.*)(\/hi|\/low)(.*)">
ForceType applicaton/octet-stream
</FilesMatch>
Now I'm not great with regex, but that seems to work in regex testers against paths like
/img/products/active/low/something.jpg
However it's not working on the site.
Any suggestions?
Thanks
Pete
This probably should have been a ServerFault question based on what I think that you're trying to do, but since you actually can't do what you're trying to do (the way I think you're trying to do it), I'll provide two alternatives; one that likely won't work, and another that involves a PHP script (which should hopefully be alright for you, since your question history shows you asking something about PHP before).
The Problem:
First, what I think you're trying to do, so you can correct me if I'm wrong:
# Apply ForceType to anything that's in a path that matches this
<FilesMatch "img/products/[^/]+/(hi|low)/[^/]+$">
ForceType applicaton/octet-stream
</FilesMatch>
However, this won't work, because FilesMatch only examines the filename, under the assumption that you could either appropriately place the .htaccess file, or combine the directive with a Directory statement in the server or virtual server configuration.
In your case though, this isn't possible (Well, I assume anyway, maybe you do have access to the necessary configurations, but since your question is tagged .htaccess I'm guessing probably not), given that copying a .htaccess file to every folder isn't realistic.
The Solutions:
As it turns out, mod_rewrite, along with performing all sorts of voodoo in the way of filename resolution, also gives you extensions of other Apache functionality that you would not necessarily have been able to use otherwise. Case in point, we can set the MIME type using the T flag, making the easiest solution this:
RewriteEngine On
# Force the MIME-type, but don't actually perform a rewrite
RewriteRule ^img/products/[^/]+/(hi|low)/[^/]+$ - [T=application/octet-stream]
This actually works pretty well, but chances are good that your Apache installation thinks that it knows better than you, and includes a mimes.types file in the main configuration that maps the jpg extension to image/jpeg. This value takes precedence over the RewriteRule, making it ineffective in that case.
The other solution is to create a small script that acts as the go-between, passing the appropriate headers and image data from the server to the client. You would then use mod_rewrite to pass the request on to that script:
RewriteEngine On
# For an added bit of sanity, make the test pattern even more restrictive
RewriteRule ^img/products/[A-Za-z._-]+/(hi|low)/[A-Za-z._-]\.[A-Za-z]+$ imageDownloader.php
As for the script itself, to keep this answer from getting ridiculously long, I suggest taking a look at this answer or one of the other questions on this topic, keeping in mind that it's imperative that you screen the filenames that can be downloaded for reasons of security. Note that you would be able to get the original request path from $_SERVER['REQUEST_URI'], and could use that to locate the proper image.