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;
Related
first of all apologies for my English, since it is not very good. I am a novice in nginx and I have a fundamental doubt:
What is the easiest way to serve several projects with nginx (separated in different directories), using a single machine, with the same ip and same port?
example.com/project1
example.com/project2
example.com/project3
A cordial greeting.
You will want several location directives inside a single server block to do what you need to do for each project. What goes inside of the location directives really depends on the type of projects they are. I have some WordPress instances, for example, that would have fastcgi config lines inside of those location directives.
Example:
server {
listen 80;
server_name example.com;
location /project1 {
# What goes here depends on what type of project this is.
}
location /project2 {
# What goes here depends on what type of project this is.
}
location /project3 {
# What goes here depends on what type of project this is.
}
}
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 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 .
I have the following Nginx configuration using regular expression server names, so I can easily add static sites without adding new configuration entries:
server {
server_name ~^(?<domain>.+)$;
root /home/static/sites/$domain;
access_log /var/log/nginx/$domain-static-access.log;
error_log /var/log/nginx/$domain-static-error.log;
}
This works fine for serving the site, and the access logs end up at e.g. /var/log/nginx/example.com-static-access.log as desired. But the error logs end up at /var/log/nginx/$domain-static-error.log. It does not interpolate the value of that regex capture.
Any idea how to fix that?
Only some nginx configuration directives support variables. Whether or not variables are supported by a particular configuration directive in a particular parameter is explicitly documented. E.g., the access_log directive description say:
The file path can contain variables (0.7.6+), but such logs have some constraints...
The error_log directive does not support variables at all, and accordingly its description doesn't say anything about variables support. Note that this is intentional: error logs are to log errors, including low-level ones like memory allocation errors, and error logging is designed to avoid operations which can fail.
In other words, error_log does not support variables and there are no plans to add such a support. Use some fixed name instead.
Well then, take a look at this. Indeed, it seems to be that error_log path won't accept variables in nginx configuration file.
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;
}