-
This forum has been archived. New threads and replies may not be made. All add-ons/resources that are active should be migrated to the Resource Manager. See this thread for more information.
Setup SEO Full Friendly URLs on nginx
- Thread starter mlx
- Start date
Floren
Well-known member
Internal requests are (only) the following:
- requests redirected by the instruction error_page
- sub-requests created by the command include virtual of the "ngx_http_ssi_module" module
- requests changed by the instruction rewrite of the "ngx_http_rewrite_module" module
Which arguably makes it more flexible than a simple allow/deny?
Floren
Well-known member
Why do you say that?
allow/deny and internal have totally different functions, into Nginx configuration.
Please read the Wiki for more details.
Blandt
Well-known member
Although I never used Litespeed, (I thought it's a commercial server) nginx is super, and you would probably find more help in "Google world ".
Nginx is easy to learn and configure, so it's really up to you. Litespeed is very good from what I hear, (i might give it a go and try it out)
Blandt
Well-known member
the Litespeed pros are obviously the out of the box compatibility with apache and the cons are $$ 
in that case if you are paying extra for litespeed , without hesitation I would switch to nginx.
and we are here to help. Also wordpress configuration is very detailed at nginx.org
If you need a manual you let me know. I have the recent one
in that case if you are paying extra for litespeed , without hesitation I would switch to nginx.
and we are here to help. Also wordpress configuration is very detailed at nginx.org
If you need a manual you let me know. I have the recent one
Floren
Well-known member
Hi Andy,
You will not see any performance gains with Nginx, compared to LiteSpeed (commercial).
The only difference is that you will save the monthly costs. Personally, I would move to Nginx if I want to be able to tweak every server aspect. LiteSpeed is not as flexible, related to that matter.
I'm well aware they are different, i also aware that internal should be used here rather than allow/deny. Using allow/deny you expose the existence of files and folders, as it returns a 403 error when you access it, where as "internal" returns a 404 error. Relying on security through obscurity is bad i know, but as additional security it is fine.
But in the end, what would be the point of "internal" if it isnt this? Why would you use allow/deny over internal for this?
Floren
Well-known member
Can you explain why you think is the appropriate way?The internal directive is the appropriate way, both work fine however. unless you are toooo paranoid
Blandt
Well-known member
That's what the manual said. I use "everything for dummies" with anything
Hang on let me quote.
Floren
Well-known member
From the start, internal was designed to be used as internal 404, as explained in the Wiki. I don't understand why you keep saying that is better to use it, when the function was not designed for the purpose of blocking access to a location?
Floren
Well-known member
Show me where the manual says that internal is designed to block access to a location or that is the appropriate way to use it for blocking an IP/user to access a location, instead of allow/deny.That's what the manual said. I use "everything for dummies" with anything
Hang on let me quote.
Blandt
Well-known member
quote from PACKET nginx http server :
In our case, we're specifying that those folder are for internal use only. They will not accept external requests.
the " deny all " is how apache does things.
Code:
internal
Context: location
This directive specifies that the location block is internal; in other words, the specified resource cannot be accessed by external requests.
server {
[…]
server_name .website.com;
location /admin/ {
internal;
}
}
With the previous configuration, clients will not be able to browse http://website.com/admin/. Such requests will be met with 404 Not found errors. The only way to access the resource is via internal redirects (check the Rewrite module section for more information on internal redirects).In our case, we're specifying that those folder are for internal use only. They will not accept external requests.
the " deny all " is how apache does things.
Blandt
Well-known member
Furthermore here is the appropriate use for "deny all" directive :
Code:
This directive allows you to prevent the use of all HTTP methods, except the ones that you explicitly allow.
Within a location block, you may want to restrict the use of some HTTP methods, such as forbid clients from sending POST requests. You need to define two elements—firstly, the methods that are not forbidden (the allowed methods; all others will be forbidden). Secondly, the audience that is affected by the restriction.
location /admin/ {
limit_except GET {
allow 192.168.1.0/24;
deny all;
}
}
This example applies a restriction to the /admin/ location—all visitors are only allowed to use the GET method. Visitors that have a local IP address, as specified with the allow directive (detailed in the HTTP Access module), are not affected by this restriction. If a visitor uses a forbidden method, Nginx will return in a 403 Forbidden HTTP error. Note that the GET method implies the HEAD method
(if you allow GET, both GET and HEAD are allowed).
