Make 1 root file accessible, and serve it for all requests

I have a version of this working, but I suspect my solution is not the
best
one.

Please suggest any improvements I can make to my conf file. I am
attempting
to do the following:

  1. If any file is requested from the root, we should always serve
    “index.html”. No other file should be accessible, and requesting
    anything
    else should be treated as if you requested “index.html”. Currently I’m
    using rewrite, but a redirect would be okay too, and possibly
    preferable.

  2. Any file under “/css” or “/js” can be requested, and requesting files
    from those directories that don’t exist should return a 404.

Here’s my current working conf file:

— BEGIN CODE ----
server {
listen 80;
server_name www.example.com;
client_max_body_size 50M;

  root /var/www/mysite;

  location = /index.html {
  }

  # map everything in base dir to one file
  location ~ ^/[^/]*$ {
    rewrite ^/[^/]*$ /index.html;
  }

  location ~ ^/css/ {
  }

  location ~ ^/js/ {
  }
}

— END CODE ----

Thanks!
Jonah

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,243881,243881#msg-243881

server {
listen 80;
server_name www.example.com;

root /var/www/mysite;

location / {
    # Default location, request will fallback here if none other

location block matches
rewrite ^.*$ / permanent; # Permanent (HTTP 301) redirection to
‘root’ location ‘/’
}

location = / {
    # 'root' location, will be served by the index directive (which

defaults to the ‘index.html’ value)
# You could also use ‘/index.html’ and thus not using the index
directive (don’t forget to change the rewrite in previous location
block)
}

location /css/ {
    # Will serve the corresponding directory. Avoid using regex

whenever possible if you can, that’ll hopefully save some CPU
}

location /js/ {
    # Idem as previous block
}

}

Note 1:
Your configuration includes a
‘client_max_body_sizehttp://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size
directive.
Its documentation is not very clear as it seems to mix up ‘client
request
body size’ with the ‘Content-Length’ HTTP header field which represents
the
‘answer body size’, the size of the file sent after the answer header.
I just checked my own configuration to be sure (I serve files bigger
than 1
MiB), but I guess you don’t need this directive to serve any file,
whatever
its size.

Note 2:
Check the directives in the parent ‘http’ block to ensure that no
‘autoindexhttp://nginx.org/en/docs/http/ngx_http_autoindex_module.html#autoindex
directive is to be found or if it is, that it is set to ‘off’. When not
set, it defaults to ‘off’.
Check also there that the
‘indexhttp://nginx.org/en/docs/http/ngx_http_index_module.html#index
directive is not set since all you want is the default ‘index.html’
value.
You can override it in your server block if you need another value at
the
‘http’ block level.

B. R.

B.R.,

Thanks very much! That was incredibly helpful. I had to make a couple
minor tweaks to get it working, and I wanted a 302 instead of a 301, but
the
following is what I ended up with, and it had the added benefit of
cutting
response time almost in half when I did a load test:

server {
listen 80;
server_name example.com;

root /var/www/register;

location = /index.html {
}

Default location, request will fallback here if none other

location block matches

location / {
rewrite ^.*$ /index.html redirect; # ‘root’ location ‘/’
}

location /css/ {
}

location /js/ {
}

}

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,243881,243893#msg-243893

I’m glad it helped. Maybe there are still some improvements, I’ll let
others pointing them out…

You must have good reasons for preferring temporary redirects other than
permanent ones, but if you really wants to redirect all traffic to the
index and you don’t serve existing files using their direct URI later,
using the permanent redirection mechanism takes advantage of the browser
cache to avoid getting hit with the same request later… Saves bandwith
+
requests processing time.

However, if the client is in some way authenticated and may access those
protected resources later, then that may be a problem indeed… ^^

I guess you know what you are doing already. Just sayin’.

B. R.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs