[linux-l] nginx (war: htaccess-Konzept)

[Volker Diels-Grabsch]

Olaf Radicke schrieb:
> Volker Diels-Grabsch <v at njh.eu> hat am 28. Juli 2015 um 17:33 geschrieben:
> > Übringens: Eine gute Nginx-Konfiguration ist in meinen Augen deutlich
> > klarer und lesbarer als jede Apache-Konfiguration.  Aber das nur am
> > Rande.
> 
> Das ist auch mein Eindruck. Ich hatte sogar schon angefangen gehabt
> den Nginx. Nur war es so, das ein Haufen Tool "Out-of-the-box" mit
> Apache können aber nur mit Anpassungen mit Nginx.

Ja, die meisten kennen nur Apache und sind darauf getrimmt.
Das ist Mist.

Dagegen hilft nur: Für mehr Verbreitung von lighttpd und nginx
sorgen! :-)


> Wenn ich das richtig gelesen habe, kann Nginx nicht in die
> auszuliefernden html Seiten eingreifen, um "http://localhost/..."
> gegen "https://pub_url.org/..." auszutauschen.

Ja, das eine Umgewöhnung von Apache.  Aber das macht auch
vieles so viel einfacher.


> Dazu braucht man wohl ein Modul http://wiki.nginx.org/NginxHttpSubsModule
> Ein mod_userdir scheint es in Nginx nicht zu geben. Stattdessen
> muss man ein Workeround benutzen: http://wiki.nginx.org/UserDir

Hab ich nie benutzt.  Will ich auch gar nicht.  Ich bin froh, dass
Nginx diesen Mist einfach mal _gar nicht_ macht.  So ist es viel
einfacher die Applikation dahinter zu fixen.

Bei Apache wusste ich nie genau, was ich in der App fixen muss und was
in der Config.  Vorallem bei Umgebungsvariablen wie PATH_INFO, die
Apache aus irgendwelchen Gründen noch irgendwie komisch tweaken muss.
Bei Nginx ist das viel einfacher und damit eindeutiger.  Kurz: Keine
App-Workarounds für Apache-Workarounds, sondern einfach alle
Workarounds loswerden.

Gute Web-Applikationen nutzen einfach immer relative URLs benutzt.
Oder zumindest URLs, die mit "/" beginnen (ohne "https://" und ohne
Domainname).

Also nicht:

   href="https://www.example.com/myapp/css/main.css"

sondern mindestens:

   href="/myapp/css/main.css"

oder noch besser:

   href="css/main.css"


> Hattest du schon Usecases die du nicht mit nginx hin bekommen hast?

Ja, es gibt eine sehr spezielle Sache, für die ich doch wieder Apache
nehmen musste: Um einen Subversion-Server via HTTPS aufzusetzen.
Dafür gibt es nämlich AFAIK kein separates Tool. (Das gibt's nur
für Subversion durch SSH getunnelt, AFAIK.)

Sondern das geht nur über ein Apache-Modul von Subversion.  Ich
hatte dann exakt dafür noch einen Apache aufgesetzt, in dem nur
das Subversion-Zeugs läuft, und den via ReverseProxy hinter Nginx
gesetzt.  So hatte ich den Apache-Overhead nur für den Subversion-
Krempel.

Und als das letzte Subversion-Repository nach Git migriert war, konnte
ich diese eine letzte Apache-Instanz auch endlich abschalten. :-)


Gruß
Volker

-- 
Volker Diels-Grabsch
----<<<((()))>>>----