mod_rewrite - ¿Cómo controlar el orden de coincidencia de la directiva ''Ubicación'' de NGINX?

nginx rewrite url

Question

Estoy tratando de optimizar mis directivas de ''ubicación'' y no puedo encontrar una buena manera de determinar si se intenta siquiera una coincidencia de ubicación específica. Usar echo dentro del bloque de ubicación no ayuda aquí.

La documentación de NGINX ngx_http_core_module es algo confusa.

Para usar expresiones regulares, debes usar un prefijo:

1. ~ Para coincidencias sensibles a mayúsculas y minúsculas

2. ~* Para emparejamiento insensible a mayúsculas

Cómo se realiza el partido:

1. Directivas con el prefijo = que coinciden exactamente con la consulta. Si se encuentra, la búsqueda se detiene.

2. Todas las directivas restantes con cuerdas convencionales. Si esta coincidencia utiliza el prefijo ^~ , la búsqueda se detiene.

3. Expresiones regulares, en el orden en que se definen en el archivo de configuración.

4. Si # 3 produjo una coincidencia, se usa ese resultado. De lo contrario, se utiliza la coincidencia de # 2.

El número 2 aquí dice "cadenas convencionales", pero luego dice que se puede usar con el prefijo ^~ . ¿No implica un RegExp? Si no, ¿cómo determina qué es un no es un RegExp?

Específicamente, quiero lo siguiente:

1. Servir cualquier cosa fuera de literal /assets directamente. PARAR BÚSQUEDA.

2. Sirva cualquier cosa que coincida con RegExp /.php$|/$ través de la búsqueda rápida de detener el CGI.

3. Servir todo lo demás directamente a través de literal /

De esta manera, solo hay un intento / coincidencia para archivos no dinámicos servidos desde fuera de los activos.

Yo tengo:

location ^~ /assets {} # search-terminating literal? or regex?
location ~ /.php$|/$ {}
location / {} # is this match always attempted?

Desde el documento, parece que el orden real sería 1-3-2, ejecutando siempre el literal / match. Sí, esta optimización no hará ninguna diferencia para el rendimiento real, pero solo quiero aclarar algo de ambigüedad.

Answer 1

De la wiki:

location = / {
# matches the query / only.
[ configuration A ]
}
location / {
# matches any query, since all queries begin with /, but regular
# expressions and any longer conventional blocks will be
# matched first.
[ configuration B ]
}

Entonces, esto coincidirá primero: location ~ /.php$ {}

A pesar de que los activos se sirven fuera de la location / {}

Dentro del bloque php, también debes asegurarte contra las cargas maliciosas antes de pasar a fastcgi:

if ($uri ~* "^/uploads/") {
return 404;
}

Como puede ver, nginx funciona un poco diferente de lo que podría esperar.