Grundlagen des statischen Website-Hostings: Index-Dateien, saubere URLs, abschliessende Schrägstriche und die Deploy-Reihenfolge für fingerprinted Assets

Worum es geht

Eine statische Website ist ein Verzeichnisbaum, der unverändert ausgeliefert wird. Drei Zuordnungsregeln entscheiden, was eine URL zurückgibt. Erstens die Index-Regel: Die nginx-Direktive index legt fest, welche Dateien verwendet werden, wenn eine Anfrage mit einem Schrägstrich endet, geprüft in Reihenfolge, und die Dokumentation weist darauf hin, dass die Verwendung einer Index-Datei eine interne Weiterleitung auslöst, sodass die Anfrage von einer anderen Location bearbeitet werden kann. Zweitens die Suchreihenfolge für saubere URLs: nginx try_files prüft die Existenz von Dateien in der angegebenen Reihenfolge und verwendet die erste gefundene, wobei $uri/ auf ein Verzeichnis prüft und ein abschliessendes =404 diesen Status zurückgibt; try_files $uri $uri/index.html $uri.html =404; liefert /about aus about.html oder about/index.html. Drittens die Schrägstrich-Regel: /docs und /docs/ sind unterschiedliche URLs, und eine der beiden sollte dauerhaft auf die andere weiterleiten, damit nur eine verlinkt und indexiert wird.

Warum es wichtig ist

Diese Regeln legen den URL-Raum der Website für Jahre fest; sie später zu ändern bedeutet Weiterleitungen. Sie entscheiden auch über den Unterschied zwischen einer Seite und einem Fehler: Ein falsch konfigurierter Fallback, der bei unbekannten Pfaden die Startseite ausliefert, macht aus jedem Tippfehler ein 200 (ein Soft-404).

So wird es angewendet

• Für jede Seite eine URL-Form wählen (/about/ mit about/index.html, oder /about mit about.html) und Generator, Serverregeln und interne Links darauf abstimmen.
• Für jede von der Website verwendete Dateiendung den korrekten Content-Type senden (.webmanifest, .svg, .wasm, .xml); eine unbekannte Endung fällt auf den Standardtyp des Servers zurück.
• Assets fingerprinten (app.3f9c1b.css) und ihnen eine lange Gültigkeitsdauer geben; HTML eine kurze geben oder eine Revalidierung verlangen, damit ein Deploy beim nächsten Seitenaufruf sichtbar wird. Der Artikel zu Cache-Control behandelt die Direktiven.
• In der sicheren Reihenfolge deployen: zuerst neue Assets hochladen, dann das HTML, das darauf verweist, und alte Assets mindestens so lange behalten, wie HTML in Caches liegen kann; eine gestern zwischengespeicherte Seite muss das gestrige CSS noch finden.
• Das Deploy dort atomar gestalten, wo der Host es erlaubt (in ein neues Verzeichnis hochladen, einen Symlink oder Release-Zeiger umschalten), damit keine Anfrage einen halb kopierten Baum sieht.
• Eine echte 404-Datei mit Status 404 ausliefern und Verzeichnislisten deaktiviert lassen.

Stolpersteine

Zwei Index-Kandidaten (index.html und index.htm) im selben Verzeichnis erzeugen eine Mehrdeutigkeit, die niemand bemerkt, bis eine veraltete Datei gewinnt. Generatoren, die sowohl about.html als auch about/index.html erzeugen, schaffen doppelte URLs. Das Löschen alter fingerprinted Assets beim Deploy zerstört Seiten, die in Browsern noch offen sind.