Pseudo-static details of Nginx server rewrite-1024programmer

During the migration process to a new host, the biggest difficulty is the setup of WP permalink rewrite.

Because the old host is using Apache,
The .htaccess that can be changed by WP itself is used without too much difficulty. This time, Nginx is running on VPS, mainly because Nginx is much faster than Apache.

But on the other hand, it is not so comfortable, because Nginx’s rewrite is different from Apache, and it can only be changed on the server.

The following are some research notes during the period. (The following examples are taken from nginx wiki unless otherwise specified)

/1 Nginx rewrite basic syntax

The rewrite syntax of Nginx is actually very simple. The instructions used are nothing more than these

set

return

break

rewrite

Although the sparrow is small, it has all internal organs. Just a few simple instructions can make a simple and flexible configuration that is absolutely not inferior to apache.

1.set

set is mainly used to set variables, nothing special

2.if

if is mainly used to judge some conditions that cannot be directly matched in the rewrite statement, such as detecting whether a file exists or not, http
header, COOKIE, etc.,

Usage: if(condition) {…}

– When the condition in the if expression is true, execute the statement in the if block

– When the expression is just a variable, if the value is empty or any string starting with 0 will be treated as false

– When comparing content directly, use = and !=

– When using regular expression matching, use

~ case sensitive matching
~* case-insensitive matching
!~ case-sensitive mismatch
!~* case-insensitive mismatch

These few sentences seem a bit convoluted, but in short, remember: ~ is a regular match, the post * is case-insensitive, and the preposition ! is “not” operation

By the way, because nginx uses curly braces {} to judge blocks, when regular braces are included, double quotes must be used to wrap regular expressions. The same is true for the regular expressions in the rewrite statement mentioned below.
For example “\d{4}\d{2}\.+”

– use -f,-d,-e,-x to detect files and directories

-f check for file existence
-d detect directory existence
-e detect the existence of a file, directory or symbolic link
-x detects that the file is executable

Similar to ~, prepended! is “not” operation

example

if ($http_user_agent ~ MSIE) {
rewrite ^(.*)$ /msie/$1 break;
}

//If the UA contains “MSIE”, rewrite the request to the /msie directory

if ($http_COOKIE ~* “id=([^;] +)(?:;|$)” ) {
set $id $1;
}

//If the COOKIE matches the regularity, set the variable $id equal to the regular reference part

if ($request_method = POST ) {
return ;
}

//If the submit method is POST, return status 405 (Method not allowed)

if (!-f $request_filename) {
break;
proxy_pass http://127.0.0.1;
}

//If the requested file name does not exist, reverse proxylocalhost

if ($args ~ post=){
rewrite ^ http://example.com/ permanent;
}

//If the query string contains “post=140”, permanently redirect to example.com

3. return

return can be used to directly set the HTTP return status, such as 403, 404, etc. (301, 302 cannot be returned by return, which will be mentioned in rewrite below)

4. break

Immediately stop rewrite detection, and the break of rewrite mentioned below
The flag function is the same, the difference is that the former is a statement, and the latter is the flag of the rewrite statement

5. rewrite

The core function (nonsense)

Usage: rewrite regular replacement flag

There are four flags

break ? Stop rewrite detection, that is to say, when it contains break
When the rewrite statement of flag is executed, the statement is the final result of rewrite
last ?
Stop rewrite detection, but it is essentially different from break. The last statement is not necessarily the final result. This will be mentioned later with the location matching of nginx
redirect? Return 302 temporary redirection, generally used to redirect to a complete URL (including the http: part)
permanent ? Return 301 permanent redirection, generally used to redirect to a complete URL (including the http: part)

Because 301 and 302 cannot simply return the status code, there must be a redirected URL, which is why the return command cannot return 301, 302.
As an alternative, rewrite can more flexibly use the redirect and permanent flags to implement 301 and 302.
For example, the domain name redirection to be done when the blog is moved as mentioned in the previous log, it will be written like this in nginx

rewrite ^(.*)$ http://newdomain.com/ permanent;

For example, let’s take a look at the practical application of rewrite

rewrite ^(/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3 last;

If the request is /download/eva/media/op1.mp3 then the request is rewritten to
/download/eva/mp3/op1.mp3

This is how it is used, it is very simple;/ {
….Configuration B
}
location ^~ /images/ {
…. configure C
}
location ~* \.(gif|jpg|jpeg)$ {
…. configure D
}

Accessing / would use configuration A -> full hit
Visiting /documents/document.html will use configuration B -> matching constant B, not matching regular C and D, so use B
Accessing /images/1.gif will use configuration C -> match constant B, match regularity C, use the first hit regularity, so use C
Visiting /documents/1.jpg will use configuration D ->
Match constant B, do not match regular C, match regular D, use the first hit regular, so use D

Then look back at the problem we just said. Why does the XHR request with a strange URL result hit location ~\.php$ instead of location
/ ? I believe you already know the answer.

So the easiest way to solve this problem is to put the rewrite rule in the server block that is executed before the location.

This is the end of this research note.

Finally, there is a question to think about. If you don’t put the rewrite rule into the server block, is there any way to solve this XHR 404 problem?

The original location / block contains the section from location ~\.php$ up to root.

The answer is there. Before using the current method, I’m keeping the location
I have tried many methods under the premise of /… Please don’t try to build independent locations for various permalinks. Because there are many types of permalinks in wp, including single articles, pages, categories, tags, authors, archives, etc.. Welcome to reply Discuss in
/

Reference:
Nginx wiki

-EOF-

Update @2010.10.23

The previous supercache rewrite rules apply to most WP. But not applicable to mobile
Mobile device support for the press plugin.

Because it doesn’t detect the user of the mobile device
agent, so that the mobile device will also be rewritten to the cache. The result is that the mobile device can also see the same full version of the blog as the PC.
For mobile phones with better performance, such as iphone and Android, there is probably no problem, but for more general ones, such as nokia, use opera
It will be more difficult for mini to wait and see. This time, the code block of supercache’s mobile device detection in htaccess is also transplanted.

Add the following code segment after the COOKIE detection in the previous configuration file

# Bypass special user agent
if ($http_user_agent ~* “2.0 MMP|240×320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP- 2.|MMEF20|MOT-V|NetFront|Newt|Nintendo Wii|Nitro|Nokia|Opera Mini|Palm|PlayStation Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian OS |SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915 Obigo|LGE VX|webOS|Nokia5800”) {
set $supercache_uri ”;
}
if ($http_user_agent ~* “w3c |w3c-|acs-|alav|alca|amoi|audi|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-|dang|doco|eric|hipt| htc_|inno|ipaq|ipod|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-|lg/u|maui|maxo|midp|mits|mmef|mobi|mot-| moto|mwbp|nec-|newt|noki|palm|pana|pant|phil|play|port|prox|qwap|sage|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie- |siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|wap-|wapa|wapi|wapp|wapr|webc |winw|winw|xda\ |xda-“) {
set $supercache_uri ”;
}

In this way, the cache rules can be bypassed for mobile devices, and the mobile version effect generated by mobile press can be used directly.