location

Syntax: location [=|~|~*|^~|@] /uri/ { … }

Voreinstellung: no

Kontext: server

Diese Direktive erlaubt unterschiedliche Konfigurationen bei URL. Es kann mit beiden Zeichenketten und regulären Ausdrücken konfiguriert werden. Um die regulären Ausdrücke zu verwenden, müssen Sie eine Präfix benutzen:

  1. “~” Unterscheidung zwischen Groß- und Kleinschreibung notwendig
  2. “~*” Unterscheidung zwischen Groß- und Kleinschreibung nicht notwendig

Um festzustellen, bei welcher Position die Direktive bei der bestimmten Abfrage übereinstimmt, werden die Zeichenketten zunächst überprüft. Literale Zeichenfolgen beginnen mit der Abfrage – die passendste Übereinstimmung wird verwendet. Danach werden reguläre Ausdrücke in der Reihenfolge, in der Konfigurationsdatei definiert und geprüft. Wenn die ersten regulären Ausdrücke passen, wird die Suche abgebrochen. Wenn keine regulären Ausdrücke gefunden werden, wird das Ergebnis aus der literalen Zeichenfolge verwendet.

Für Groß- und Kleinschreibungs-Betriebssysteme wie Mac OS X oder Windows mit Cygwin wird die literale Zeichenkette in einer Groß-und Kleinschreibung (0.7.7) durchgeführt. Allerding ist der Verglech zu Single-Byte-Locale nur begrenzt.

Es ist möglich diese regulären Ausdrücke zu deaktivieren, nachdem mit Hilfe der literalen Zeichekette von “^~” Präfix geprüft wurde. Wenn die beste Entsprechung diesen Präfix hat, werden die regulären Ausdrücke nicht überprüft.

Bei der Benutzung von “=” Präfix wird die exakte Übereinstimmung zwischen Anforderungs-URL und Standort definiert. Wenn die Suche erfolgreich war, stoppt sie sofort. Zum Beispiel wenn die Anfrage “/” häufig auftritt, mit “location = /” beschleunigt sich die Bearbeitung dieser Anfrage ein bisschen und die Suche wird nach erstem Vergleich stoppen.

Auf exakte Übereinstimmung mit der Location ohne “=” oder “^~” Präfixe, wird die Suche direkt wieder abgebrochen.

Zusammenfassend ist die Reihenfolge, in der die Direktive überprüft werden wie folgt:

  1. Direktive mit dem “=” Präfix, sucht nach übereinstimmender Abfrage. Wenn sie gefunden wurde, stoppt die Suche.
  2. Alle übrigen Direktive mit herkömmlichen Seiten. Wenn der Treffer gefunden wurde “^~”Präfix, stoppt der Suchlauf.
  3. Reguläre Ausdrücke in der Reihenfolge werden in der Konfigurationsdatei definiert.
  4. Bei Übereinstimmung von (3) wird das Ergebnis verwendet. Ansonsten wird der Treffer aus (2) verwendet.

Es ist wichtig zu wissen, dass nginx einen Vergleich gegen dekodierte URLs macht. Zum Beispiel, wenn Sie etwas anpassen möchten, “/images/%20/test”, dann müssen Sie “/images/ /test” verwenden, um die Location zu bestimmen.

Beispiel:

location  = / {
  # Zutreffend nur für /
  [ Konfiguration A ]
}
location  / {
  # Trifft auf die Anfrage zu, da die Anfragen regelmäßig mit / beginnen,
  # die reguläre Ausdrücke werden zuerst geprüft.
  [ Konfiguration B ]
}
location ^~ /images/ {
  # Trifft jede Anfrage beginnend mit /images/ und stoppt die Suche,
  # reguläre Ausdrücke werden nicht geprüft.
  [ Konfiguration C ]
}
location ~* \.(gif|jpg|jpeg)$ {
  # Trifft auf jede Anfrage endend mit gif, jpg, oder jpeg zu. Dennoch, werden
  # Anfragen an das /images/ Verzeichnis durch die
  # Konfiguration C verarbeitet.
  [ Konfiguration D ]
}

Beispiel für Anfragen:

  • / -> configuration A
  • /documents/document.html -> configuration B
  • /images/1.gif -> configuration C
  • /documents/1.jpg -> configuration D

Beachten Sie, dass Sie diese 4 Konfigurationen in beliebiger Reihenfolge definieren können und die Ergebnisse unverändert bleiben würden. Während verschachtelte Verzeichnisse durch die Konfigurationsdatei erlaubt sind, wird von ihrer Verwendung abgeraten, da es zu unerwarteten Ergebnissen führen kann.

Das Präfix “@” legt eine “named”-Location fest. Solche Locations werden nicht während der normalen Verarbeitung der Anfragen verwendet, sie sind nur für die Intern umgeleiteten Anfragen (siehe error_page, try_files) zuständig.

Gehört zu Core

limit_rate

Syntax: limit_rate Bandbreite

Voreinstellung: no

Kontext: http, server, location, if in location

Die Direktive bestimmt die Bandbreite der Übertragung der Antworten an den Clienten. Die Bandbreite ist in Bytes pro Sekunde angegeben. Die Begrenzung funktioniert nur bei einer Verbindung, d.h. wenn der Client zwei Verbindungen öffnet, wird die Geschwindigkeit 2x so hoch sein, als das festgelegte Bandbreitenlimit.

Wenn es notwendig ist, die Bandbreite für einige Clienten im Serverkontext zu begrenzen, bezogen auf den Zustand des Servers, dann findet diese Direktive keine Anwendung.

Stattdessen sollte die Bandbreite durch Zuweisung der $limit_rate Variable, wie unten dargestellt, limitiert werden:

server {
  if ($slow) {
    set $limit_rate  4k;
  }
}

Ebenso können Sie die Bandbreiten der einzelnen Antworten durch eine proxy_pass Direktive (Proxy-Modul) regeln, indem Sie den X-Accel-Limit-Rate Header setzen (X-Sendfile). Dies kann ohne ein X-Accel-Redirect Header erfolgen.

Gehört zu Core

large_client_header_buffers

Syntax: large_client_header_buffers  Anzahl   Größe

Voreinstellung: large_client_header_buffers 4 4k/8k

Kontext: http, server

Die Direktive legt die maximale Anzahl und Größe des Puffers für große Header fest, um die Client-Anfragen zu lesen.

Die Anfrage darf nicht größer sein, als die Größe eines Puffers, wenn der Client doch einen größeren Header sendet, antwortet Nginx mit der Fehlermeldung “Request URI too large” (414).

Die lange Zeile der Anfrage im Header darf nicht größer sein, als ein Puffer, anderenfalls erhält der Client die Fehlermeldung “Bad request” (400).

Standardmäßig ist die Größe eines Puffers gleich der Größe einer Speicherseite, die je nach Plattform entweder 4K oder 8K groß sein kann. Wenn am Ende der Verarbeitung der Anfrage die Verbindung in den Zustand Keep-Alive wechselt, werden diese Puffer befreit.

Gehört zu Core

keepalive_requests

Syntax: keepalive_requests  [Anzahl]

Voreinstellung: keepalive_requests 100

Kontext: http, server, location

Anzahl der Anfragen, die über eine Keep-Alive Verbindung hergestellt werden können.

Gehört zu Core

keepalive_timeout

Syntax: keepalive_timeout [ Zeit ]

Voreinstellung: keepalive_timeout 75

Kontext: http, server, location

Der erste Parameter legt den Timeout für die Keep-Alive Verbindungen mit dem Client fest. Der Server wird die Verbindungen nach dieser Zeit beenden.

Der zweite Parameter legt den Zeitwert des “Keep-Alive”-Headers fest: Timeout= Zeitbegrenzung. Dieser Header kann einige Browser davon überzeugen, die bestehenden Verbindungen zu beenden, sodass dies nicht der Server machen muss. Ohne diesen Parameter wird nginx keinen “Keep-Alive”-Header senden.

Die Parameter können voneinander abweichen.

Hinweise zum Gebrauch des “Keep-Alive”-Headers:

  • MSIE und Opera ignorieren den “Keep-Alive: timeout=<N>” Header.
  • MSIE hält die Verbindung bis zu etwa 60-65 Sekunden aufrecht, dann wird ein TCP RST gesendet.
  • Opera hält die Verbindung für eine längere Zeit aufrecht.
  • Mozilla hält die Verbindung zu N plus bis zu 1-10 Sekunden aufrecht.
  • Konqueror hält die Verbindung für N Sekunden aufrecht.
Gehört zu Core

if_modified_since

Syntax: if_modified_since [off|exact|before]

Voreinstellung: if_modified_since exact

Kontext: http, server, location

Die Direktive (0.7.24) bestimmt, wie der Zeitpunkt der Dateiänderung und die Zeit im Request-Header “If-Modified-Since” überprüft werden kann:

  • off - nicht überprüfen “If-Modified-Since” im Anfrage-Header (0.7.34);
  • exact - genau zutreffend;
  • before - die Zeit der Dateiänderung liegt vor der Zeit im “If-Modified-Since” Anfragen-Header oder gleicht sich dieser Zeit.

 

Gehört zu Core

default_type

Syntax: default_type MIME-type

Voreinstellung: default_type text/plain

Kontext: http, server, location

Es kann vorkommen, dass der Server ein Dokument ausliefern muss, dessen Typ er nicht mit Hilfe seiner MIME-Type-Zuordnungen bestimmen kann.

Der Server informiert den Clienten über den Content-Type des Dokumentes. Daher verwendet er im Falle eines unbekannten Types die default_type Direktive.

Gehört zu Core

client_max_body_size

Syntax: client_max_body_size Größe

Voreinstellung: client_max_body_size 1m

Kontext: http, server, location

Die Direktive legt die maximale Größe der Anfrage fest, die im “Content-Length”-Header der Anfrage angegeben wird.

Wenn die Anfrage Größer als die Angegebene ist, anwortet nginx mit der Fehlermeldung “Request Entity Too Large” (413).

Bitte beachten Sie, dass die Browser nicht wissen, wie sie diesen Fehler richtig anzeigen sollen.

Gehört zu Core

client_header_timeout

Syntax: client_header_timeout Zeit

Voreinstellung: 60

Kontext: http, server

Die Direktive bestimmt den Timeout für das Lesen des Headers vom Client.

Wenn der Client nach dieser Zeit nichts sendet, antwortet nginx mit der Fehlermeldung “Request time out” (408).

Gehört zu Core

client_header_buffer_size

Syntax: client_header_buffer_size Größe

Voreinstellung: 1k

Kontext: http, server

Die Direktive legt die Größe des Puffers für den Request-Header fest.

Für die meisten Anfragen würde die Größe des Puffers von 1K volkommen ausreichend sein.

Wenn jedoch ein Client größere Cookies sendet, muss diese Direktive vergrößert werden, wenn der Header sonst nicht in diesen Puffer passt, wird nginx mit dem Fehler “Bad Request” (400) antworten.

Gehört zu Core