I'm using nginx/1.10-3 and apache2-2.4.25-3 on Debian.
For many reasons i won't go into, I'm looking to switch to NGINX from Apache2.
My CMS has many files that either have no extensions, or have the wrong extension in terms of lining up with mime.types.
With Apache2 we rely on mod_mime_magic to override the extension and use the magic bytes to correctly set the content-type. However, I can't seem to find a way to get this on NGINX.
For example, we have images that end in .img and some files with no extension at all.
The only solution I can come up with, is to integrate extension rewriting/adding into the platform and change the extensions on upload and go through the existing ones. This will take a lot more time, though.
Is there a "hack" or an alternative to mime magic with NGINX?
Thanks
Related
I am rather new to TYPO3. Recently I noticed some very weird behavior in my installation: Some CSS-files in the directory typo3temp/assets/compressed got the MIME-type text/html instead of the expected text/css. Therefore my browser received a 403 Forbidden status code from the webserver for these resources. That resulted in some parts of the backend being shown without styling.
I tried clearing all caches and deleting the typo3temp/assets/compressed directory, however now all the stuff in there (CSS and JS) is served with MIME-type text/html. Getting the backend without JavaScript means, that I am now basically locked out of the backend. I can however still reach and use the install tool.
Do you have any ideas how this might happen and how to fix it?
Some details of my setup:
TYPO3 v10.4.13 (recently updated from 10.4.9)
Apache web server (I don't have access to its config and have to rely on .htaccess files)
I suggest to set
TYPO3_CONF_VARS/FE/compressionLevel=0
TYPO3_CONF_VARS/BE/compressionLevel=0
in order not have these kind of problems. The problem is that this compression creates compressed files but relies on webserver configuration in order to deliver them as text/css and NOT applying the default webserver's transport compression to them (or they could end up double-compressed and you might not even easily notice - some browsers can deal with that, others not).
It is a kind of micro-optimization that sounded useful in times when we avoided https:// because of the processing overhead...
Here's some docs (the first statement is outdated in my oppinion): https://docs.typo3.org/m/typo3/reference-skinning/master/en-us/BackendCssApi/CssCompression/Index.html
I am currently migrating my website from Apache to nginx, but my .htaccess file is not working. My website is inside the /usr/share/nginx/html/mywebsite folder. How can I use .htaccess in my nginx server?
This is my .htaccess file:
RewriteEngine on
RewriteRule video/watch/([a-zA-Z0-9_#$*-]+)/?$ "videos-single.php?id=$1" [NC]
Nginx doesn't support .htaccess (see here: "You can’t do this. You shouldn’t. If you need .htaccess, you’re probably doing it wrong.").
You've two choices (as I know):
import your .htaccess to nginx.conf (maybe the htaccess to nginx converter helps you)
use authd-htpasswd (I didn't try it)
Disclosure: I am the author of htaccess for nginx, which is now open source software.
Over the past years, I created a plugin which implements htaccess behaviour into nginx, especially things like RewriteRule, Allow and Deny, which can be crucial for web security. The plugin is used in my own productive environments without a problem.
I totally share the point of efficiency and speed in nginx, and why they didn't implement htaccess.
However, think about it. You cannot make it worse if you're using nginx plus htaccess. You still keep the great performance of nginx, plus you can drive your legacy appliances effortlessly on one webserver.
This is not supported officially in nginx. If you need this kind of functionality you will need to use Apache or some other http server which supports it.
That said, the official nginx reasoning is flawed because it conflates what users want to do with the way it is done. For example, nginx could easily check the directories only every 10 seconds / minute or so, or it could use inotify and similar mechanisms. This would avoid the need to check it on every request... But knowing that doesn't help you. :)
You could get around this limitation by writing a script that would wait for nginx config files to appear and then copy them to /etc/nginx/conf.d/. However there might be some security implications - as there is no native support for .htaccess in nginx, there is also no support for limiting allowed configuration directives in config files. YMMV.
Using the config file is one option, but the cool thing about the .htaccess file is that it provided a way for a web developer to have some control over server settings without having root access to the server. There doesn't seem to be anything like this on nginx which is a real bummer.
I understand how the way it's setup on apache slows down response times, but hoped there could be an nginx way to do the same thing without the performance hit... At least a way to do rewrites with regex on urls if nothing else.
"Is there no nginx way to do bulk redirects using regular expressions that doesn't slow down response times."
Just edit your database with myphpmyadmin.
Open myphpmyadmin select your database then find your "yourprefix_Posts" table.
Open it then click the "Search" tab, then "Find and Replace".
Select "post_content" in the dropdown
In the "Find" field, type URL you want to change: "website.com/oldURL".
In the "Replace" field, type the new URL: "website.com/newURL".
(To use regular expression, tick the "Regular Expression" box.)
NOTE: You can test this out by simply leaving the "Replace" field blank.
ALWAYS BACKUP database before making changes. This might sound scary but its really not. Its super simple and can be used to quickly replace just about anbything.
I am changing some of my PHP settings such as upload size limit etc.
I manage to increase my upload size limit with some modifications to my Loaded Configuration File: php5.ini.
So it is the right file, and changes to php5.ini takes effect.
I want to enable ldap extension too. However, i couldnt do that. I added the following line:
extension=php_ldap.dll
But it did not take any effect.
Can anybody see why?
Thanks!
If you're on Linux, adding a dll extension won't do much good since these are used by Windows.
You'd rather have to enable the .so extension.
But then again just uncommenting or adding this entry in your php.ini doesn't make the extension work automatically, it will work only if the given .so file is really there and is in the right path, resp. the path is configured correctly.
If you're on Linux and you've got a chance, you should install extensions via your package manager (apt, yum, ...) which will compile the extension into your php installation. This way you won't loose your extension after server updates which include php.
If you don't have access to your server, there is always something you can do!
a) Ask the hosting provider to enable the extension for you, good hosting providers do that.
b) Get a VPS. You'll be so much better off!! It's worth it! Check out ServerGrove!
Is there any way to automatically minify static content and then serve it from a cache automatically? Similar to have mod_compress/mod_deflate work? Preferably something I could use in combination with compression (since compression has a more noticeable benefit).
My preference is something that works with lighttpd but I haven't been able to find anything, so any web server that can do it would be interesting.
You can try nginx's third party Strip module:
http://wiki.nginx.org/NginxHttpStripModule
Any module you use is just going to remove whitespace. You'll get a better result by using a minifier that understands whatever you're minifying. e.g. Google's Closure javascript compiler.
It's smart enough to know what a variable is and make it's name shorter. A whitespace remover can't do that.
I'd recommend minifying offline unless your site is very low traffic. But if you want to minify in your live environment I recommend using nginx's proxy cache. (Sorry but I don't have enough reputation to post more than one link)
Or you can look into memcached for an in-memory cache or Redis for the same thing but with disk backup.
I decided to do this through PHP (mostly because I didn't feel like writing a lighttpd module).
My script takes in a query string specifying the type of the files requested (js or css), and then the names of those files. For example, on my site the CSS is added like this:
<link rel="stylesheet" href="concat.php?type=css&style&blue" ... />
This minifies and concatenates style.css and blue.css
It uses JSMin-PHP and cssmin.
It also caches the files using XCache if it's available (since minifying is expensive). I actually plan to change the script so it doesn't minify if Xcache isn't available, but I have Xcache and I got bored.
Anyway, if anyone else wants it, it's here. If you use mine you'll need to change the isAllowed() function to list your files (it may be safe to make it just return true, but it was easy to just list the ones I want to allow).
I use Microsoft Ajax Minifier which comes with a C# library to minify js files. I use that on the server and serve up a maximum of two minified .js files per page (one "static" one that is the same across the whole site, and one "dynamic" one that is specific to just that page).
Yahoo's YUI compressor is also a simple Java .jar file that you could use as well.
The important thing, I think, is not to do it on a file-by-file basis. You really do need to combine the .js files to get the most benefit. For that reason, an "automatic" solution is not really going to work - because it will necessarily only work on a file-by-file basis.
If you use Nginx instead of lighttpd then you can take advantage of Nginx's embedded Perl support to leverage the Perl module JavaScript-Minifier to minify and cache JS server-side.
Here are the details on how to achieve this: wiki.nginx.org/NginxEmbeddedPerlMinifyJS
The webserver hosting my website is not returning last-modified or expiry headers. I would like to rectify this to ensure my web content is cacheable.
I don't have access to the apache config files because the site is hosted on a shared environment that I have no control over. I can however make configurations via an .htaccess file. The server - apache 1.3 - is not configured with mod_expires or mod_headers and the company will not install these for me.
With these limitations in mind, what are my options?
Sorry for the post here. I recognise this question is not strictly a programming question, and more a sys admin question. When serverfault is public I'll make sure I direct questions of this nature there.
What sort of content? If static (HTML, images, CSS), then really the only way to attach headers is via the front-end webserver. I'm surprised the hosting company doesn't have mod_headers enabled, although they might not enable it for .htaccess. It's costing them more bandwidth and CPU (ie, money) to not cache.
If it's dynamic content, then you'll have control when generating the page. This will depend on your language; here's an example for PHP (it's from the PHP manual, and is a bad example, as it should also set the response code):
if (!headers_sent()) {
header('Location: http://www.example.com/');
exit;
}
Oh, and one thing about setting caching headers: don't set them for too long a duration, particularly for CSS and scripts. You may not think you want to change these, but you don't want a broken site while people still have the old content in their browsers. I would recommend maximum cache settings in the 4-8 hour range: good for a single user's session, or a work day, but not much more.