|
|
# Nginx Config
|
|
|
|
|
|
|
|
|
|
|
|
## Allgemeines
|
|
|
|
|
|
Nginx ermöglicht es nicht eine Config-datei im Verzeichnis anzulegen, wie Apache es mit der .htaccess handhabt.
|
|
|
Anstatt dessen liest Nginx Directorybezogene Anweisungen beim Dienststart ein.
|
|
|
Diese Anweisungen werden in einer Zentralen ConfigDatei verwaltet und bestehen aus Anweisungsblöcken.
|
|
|
Die zwei Hauptarten jener Blöcke sind Server- und Locationblöcke.
|
|
|
|
|
|
### Http Block
|
|
|
Der Http Block enthält alle Server übergreifenden Konfigurationen.
|
|
|
|
|
|
### Server Block
|
|
|
Der Serverblock enthält Anweisungen, die den VHost betreffen.
|
|
|
Also insbesondere die IP bzw. den Port auf welchen der VHost reagiert und auf welche Domain er ansprechen soll.
|
|
|
|
|
|
**listen**: Angabe auf welcher IP-Adresse/welchem Port reagiert werden soll .
|
|
|
*Beispiel : listen 0.0.0.0:80; oder listen 80;*
|
|
|
|
|
|
|
|
|
**server_name**: Angabe auf welche Domain reagiert werden soll. Je genauer, desto höher die Priorität.
|
|
|
_Beispiel : \*.example.com oder example.com_
|
|
|
|
|
|
### Location Block
|
|
|
Ein Serverblock kann mehrere Locationblöcke beinhalten.
|
|
|
Locationblöcke sind grundlegend das Äquivalent zur .htaccess Datei.
|
|
|
Sie ermöglichen Konfigurationsdirektiven zu einem bestimmten Ort anzugeben.
|
|
|
|
|
|
Die Syntax des Location-Blocks ist wie folgt :
|
|
|
location *modifier* *path* { *Anweisungen* }
|
|
|
|
|
|
|
|
|
Wobei der Modifier wie folgt ausfallen kann :
|
|
|
|
|
|
|
|
|
|Modifier | Bedeutung |
|
|
|
|-------------|-----------------|
|
|
|
| (leer)| Prüft als Prefix. matcht, wenn URI damit anfängt|
|
|
|
| = | Exakt. Matcht nur bei exaktem Treffer. |
|
|
|
| \~ | RegEx. Matcht einen Regulären Ausdruck. |
|
|
|
| \~\* | RegEx. Matcht einen **case-insensitiven** Regulären Ausdruck |
|
|
|
| \^\~ | Versucht diesen String in der Url zu finden. Verhindert RegEx matching|
|
|
|
|
|
|
**Path**
|
|
|
Der *path* Beschreibt die request_uri, als den Teil nach der Host-Angabe.
|
|
|
Hierbei ist zu beachten, dass Nginx einen führenden "/" beachtet.
|
|
|
http://localhost/test/ müsste also mit location = /test/ gematcht werden.
|
|
|
|
|
|
|
|
|
|
|
|
**Reihenfolge der Selektion**
|
|
|
Da wir nun betrachtet haben, wie ein Locationblock aufgebaut ist, werden wir nun genauer betrachten, wie der Server den zu verwendenden Locationblock auswählt.
|
|
|
|
|
|
Nginx verwendet einen umfangreichen Algorithmus, welcher bei jedem Request einen passenden Locationblock sucht.
|
|
|
|
|
|
Kurz zusammengefasst sehen die Schritte wie folgt aus :
|
|
|
|
|
|
- Prüfe nicht Reguläre Ausdrücke
|
|
|
|
|
|
- Suche zuerst exakte treffer (= modifier)
|
|
|
|
|
|
- Als nächstes werden Prefix-matches gesucht, je länger, desto höher die Priorität
|
|
|
|
|
|
- Falls beim längsten Prefix-treffer ein \^\~ modifier verwendet wird, wird dieser Treffer sofort verwendet (verhindert RegEx-Prüfung)
|
|
|
|
|
|
- Falls kein modifier verwendet wird, speichere besten Treffer zwischen
|
|
|
|
|
|
- Prüfe nun, ob RegEx Treffer möglich sind (Reihenfolge wie in der ConfigDatei)
|
|
|
|
|
|
- Hier gilt, der erste Treffer gewinnt.
|
|
|
|
|
|
- Falls kein Match durch RegEx erzielt werden konnte, verwende zwischengespeicherten Prefix-Match.
|
|
|
|
|
|
|
|
|
**Zu beachten:**
|
|
|
|
|
|
Bei machen Anweisungen, wird der Algorithmus von vorne gestartet, wenn ein interner Redirect stattfindet und nicht explizit verhindert wird.
|
|
|
Das heißt, es ist möglich in Endlosschleifen zu geraten!
|
|
|
|
|
|
|
|
|
#### Die Anweisungen
|
|
|
|
|
|
Da wir nun wissen, welcher Block selektiert wird, sollten wir uns damit befassen, was der Block bewirken kann.
|
|
|
|
|
|
Im Locationblock hat man nun diverse Konfigurationsmöglichkeiten. Unter anderem :
|
|
|
|
|
|
**index**: Man kann die Indexdatei festlegen
|
|
|
**root**: Man kann den DirectoryRoot erneut festlegen
|
|
|
|
|
|
**Besonderes Augenmerk legen wir aber auf die folgenden Direktiven:**
|
|
|
|
|
|
- return : Stoppt die weitere Bearbeitung des Requests und sendet eine Statuscode zurück. Entweder ein redirect oder ein Statuscode mit Responsetext.
|
|
|
|
|
|
- rewrite: Schreibt einen Teil der URI um und führt einen internen redirect aus.
|
|
|
|
|
|
- try_files : Prüft gegebene Dateien / Ordner auf Existenz, falls keine davon existiert wird ein interner redirect auf den letzten Parameter ausgeführt
|
|
|
|
|
|
|
|
|
**Mehr zu der Direktive : rewrite**
|
|
|
|
|
|
**Allgemeines Format : ** rewrite \<RegEx-pattern\> \<replacement\> [flag]
|
|
|
|
|
|
Ersetzt den Teil der URI, der das RegEx-Pattern "matcht" durch das angegeben Replacement.
|
|
|
Soweit nicht durch Flags behandelt, wird auf die neu entstandene URI erneut eine Suche nach passenden Locationblöcken gestartet.
|
|
|
|
|
|
|
|
|
**Flags :**
|
|
|
|
|
|
- last : Hört sofort mit Bearbeitung des Requests auf und sucht sofort nach neune Location Blöcken
|
|
|
|
|
|
- break : Stoppt Bearbeitung des Requests und sucht **keine** neue Locationblöcke.
|
|
|
|
|
|
|
|
|
## Vertiefende Literatur
|
|
|
|
|
|
- Doku : http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#return
|
|
|
|
|
|
- Requestprocessing : http://nginx.org/en/docs/http/request_processing.html
|
|
|
|
|
|
- Ausführliches rewrite Tutorial : https://www.nginx.com/blog/creating-nginx-rewrite-rules/
|
|
|
|
|
|
- .htaccess in Nginx konvertieren : https://www.nginx.com/blog/converting-apache-to-nginx-rewrite-rules/
|
|
|
|
|
|
|