I spent days now in researching on how to add some headers to nginx. All I try to do is adding these lines:
location ~ ^/(assets)/ {
add_header Access-Control-Allow-Origin *;
}
What is the best way to put these lines into the nginx.conf?
Is there also a way to not overwrite the standard nginx.conf just in case beanstalk updates the settings so I wont miss it?
The default elastic beanstalk nginx.conf seems to have this line toward the end :
include /etc/nginx/conf.d/*.conf;
(Well, I can tell you that's what the file looks like for the docker solution stack versions 1.4.1 and 2.0.4, no idea if that's guaranteed across all solution stacks).
So I think one way would be to to drop a file named whatever.conf into the /etc/nginx/conf directory using the ebextensions mechanism .
Related
I'm working on a legacy site where all urls must begin with the single available language code '/en'.
Is it possible with nginx to rewrite urls that do not begin with '/en' so that it is added (the legacy application will then be able to find the content and serve it)?
E.g.
http://www.example.com/ -> http://www.example.com/en/
http://www.example.com/page1 -> http://www.example.com/en/page1
http://www.example.com/en/page1 -> http://www.example.com/en/page1
Yes, this is possible. It's a bit difficult to give you a full solution since you haven't provided the config file, but I'll give it a shot.
You're looking for something along the lines of:
if ($request_uri !~ "^/en.*"){
return 301 $scheme://www.example.com/en$uri;
}
Note: This should appear immediately after your server_name and listen directives and not in a location block (see here).
I hope this helps.
I'm currently migrating from lighttpd to nginx.
I've got some weird files (don't ask why):
1. say a file named 'news', which actually should be more like news.txt
2. a file named '.html', which actually should be index.html
With lighttpd, simply rewrite those things would work.
Nginx would still locate those files with try_files or rewrite, but I've got no control of the content type returned. I mean if the file is named '.html', the content type is 'application/octet-stream'.
I know I can use more_set_headers to achieve that, but is there any other way to do that? I mean why does nginx think a file named '.html' not an html file?
I mean why does nginx think a file named '.html' not an html file?
A dot at the beginning in unix-like systems is usually used as the indicator of hidden files. In this case, a part after the dot isn't file extension.
I know I can use more_set_headers to achieve that, but is there any other way to do that?
You should use the default_type directive instead of 3-rd party modules.
For example:
location =/.html {
default_type text/html;
}
I want to do server side include and i have nginx server installed in my machine and i cant find a way to enable ssi in nginx.conf file?
all i can find from the internet is
syntax: ssi on | off;
default:
ssi off;
context: http, server, location, if in location
Enable ssi on the location context. In my case i want it on root
location / {
ssi on;
}
It looks like you were having the same problem I was having; finding a crystal clear explanation of how to enable SSI on NGINX. Crystal Clear entails not just which syntax to use, but the format, and exactly where to include it. I figured it out and it's not that difficult, but the lack of clear instructions on the internet was frustrating.
You'll need to open up the nginx.conf file and look for the section that is formatted as follows (I've included the 'ssi on' syntax as well):
location / {
root E:\website\FinalJRLWeb;
index index.html index.shtml;
ssi on;
}
It took me a bit to realize the location, but it's really as simple as adding the line 'ssi on' right underneath the specified index file names (and it should be able to really go anywhere you'd like, I don't imagine the order matters, just as long as it's within the two brackets {}).
After that, to verify that SSI is working on your NGINX server, add the following line anywhere in the 'body' tag of a blank html page
<!--#echo var="DATE_LOCAL" -->
and save it with the extension .shtml in your web server's root directory.
You should see the server's local date and time displayed upon visiting your page. I realize this is almost a year old, but after my frustration trying to find clear instructions, I wanted to do my best to try and provide clear instructions for anyone else that may need them. So hopefully this will help someone out!
Here's NGINX's documentation page on SSI (which honestly was not helping me as much as I would have liked, but it nonetheless is useful, and can only become more and more useful)
http://nginx.org/en/docs/http/ngx_http_ssi_module.html#ssi_last_modified
By default ssi is only apply to the text/html MIME Type; which might offer you frustration, though clearly documented here http://nginx.org/en/docs/http/ngx_http_ssi_module.html#ssi_types
you may need to add
ssi on;
ssi_types *; # Or something more specific
Enabling SSI on NGINX for a single domain
To enable SSI for just one domain (limiting possible security holes), you can add it as follows to the .conf file for that domain - in Debian these are (controversially for some) stored in the Apache-like system under "etc/nginx/sites-available".
server {
server_name mydomain.com;
root /home/username/html;
index index.html index.shtml;
location / {
ssi on;
...otherstuffhere
}
}
The crucial parts:
index index.html index.shtml;
ssi on;
Switching from apache to nginx, and encountering something weird.
1) Say I have a file yo.txt in the document root of my site and it contains 'foo'.
curl http://localhost/yo.txt => 'foo'
2) then I alter the file to contain 'bar'
curl http://localhost/yo.txt => 'foo' (still!)
If I remove yo.txt, I get a 404. If I remove all the text, I correctly get an empty file when I curl the url.
I checked the last modified HTTP header after I modify the file, and it is correct, even though the contents of the file are stale.
I'm using the standard configuration from nginx after an apt-get install nginx.
what gives?
I'm using Vagrant. Setting sendfile to off in nginx.conf fixed the problem as found here, e.g."
sendfile off;
For me the following worked:
expires modified 10y;
According to the docs:
The time in the “Expires” field is computed as a sum of the current time and time specified in the directive. If the modified parameter is used (0.7.0, 0.6.32) then the time is computed as a sum of the file’s modification time and the time specified in the directive.
I am currently working on my Wordpress blog, which is hosted on a VPS.NET VPS with Nginx as front end to Apache to serve static files, while Apache takes care of the PHP in FastCGI. This seems to be working great, however I haven't yet managed to have Nginx serve WP-SuperCache files as well, which I would like for maximum performance (I am not planning to completely replace Apache with Nginx right now because I've got a Virtualmin license and it does not support Nginx).
I have tried a lot of rules found here and there but in the end none worked for me or I am missing something.
If Apache is stopped, in fact, I can still get images, stylesheets and javascript delivered to the browser by Nginx directly.
But if I try to surf the blog (with pages cached for sure by WP-SuperCache) with Apache stopped, all I get from Nginx is a "502 bad gateway".
Any ideas would be greatly appreciated.
Many thanks in advance.
Nginx can handle your fastCGI. Bundled with Nginx, generally, all Apache does is cost you resources.
Regarding WP Super Cache, if you create a new file and paste this, it'll give you both that and, while we're about it, FURLs...
# if the requested file exists, return it immediately
if (-f $request_filename) {
break;
}
set $supercache_file '';
set $supercache_uri $request_uri;
if ($request_method = POST) {
set $supercache_uri '';
}
# Using pretty permalinks, so bypass the cache for any query string
if ($query_string) {
set $supercache_uri '';
}
if ($http_cookie ~* "comment_author_|wordpress|wp-postpass_" ) {
set $supercache_uri '';
}
# if we haven't bypassed the cache, specify our supercache file
if ($supercache_uri ~ ^(.+)$) {
set $supercache_file /wp-content/cache/supercache/$http_host/$1index.html;
}
# only rewrite to the supercache file if it actually exists
if (-f $document_root$supercache_file) {
rewrite ^(.*)$ $supercache_file break;
}
# all other requests go to Wordpress
if (!-e $request_filename) {
rewrite . /index.php last;
}
Now, goto your virtual host file, or nginx.conf if you bundle your sites, and add a line like ..
# Wordpress WP Super Cache plugin and permalinks.
include /usr/local/nginx/conf/wordpress_params.super_cache;
.. where wordpress_params.super_cache is what you called the file we created, and given a path relative to that I've shown.
Then restart Nginx and turn on WP Super Cache plugin and, for the pretty links, add a permalink structure.
Fact is, there's a lot to know about to get the Nginx install right, especially with WordPress and to configure fastCGI. If you like, this would be a good start for you...
.. Setup WordPress on NGINX (FURLs & Cache) - VPS Bible Pt 13
Re. Virtualmin .. I understand you want a CP, but truth is, the resource cost is greater than the cost of the software .. plus it takes way longer to do stuff with a CP.
I'm currently publishing a 21 part VPS Admin series which addresses the lack of an Nginx CP .. that'll be all you need, frankly.
Given a week or two, I challenge you to tell me it's quicker or otherwise better to use a CP :)
It seems silly to run Nginx through Apache.
Set up Nginx to serve up the php and dynamic pages itself and you'll have a much faster service and won't have the problem where apache dies and leaves your webserver(Nginx) hanging.
If your admin panel doesn't support this, you probably should only be using apache in the first place. Either do one or the other, both is just asking for problems.
You may use FREE WordOps - WordPress site and server administration which already offers nginx configuration option (--wpsc) for WP Super Cache and other cache plugins.