REWRITE anyone?

peterle

peterle

Forenkasper
Wenn es etwas gibt, womit ich schon immer auf Kriegsfuß stehe, dann ist es mod_rewrite und die für mich kryptische Syntax ...

Ich muß von
Code: 
https://www.example.org/directory1/directory2/index.php/t-127253.html
Nach
Code: 
https://www.example.org/directory1/showthread.php?t=127253

Und vielleicht hat ja auch einer einen Idiots Guide to Rewrite, den er empfehlen kann. :o
 
Einen Guide nicht aber ich empfehle immer Regex101.com um regexen zu testen. Da kann man sich auch Stück für Stück vorarbeiten.
 
OK, tun wir mal Butter bei die Fische ...

Code: 
https://www.hobbyschneiderin24.net/portal/archive/index.php/t-127253.html
->
https://www.hobbyschneiderin24.net/portal/showthread.php?t=127253

Ich weiß jetzt schon mal, wie ich die eigentlichen Unterschiede beschreibe
Code: 
/(archive\/index\.php\/t-)/
->
/(showthread\.php\?t=)/

Wie ich das jetzt für Apache verständlich in die .htaccess kriege, allerdings noch nicht ... mal schauen ...
 
Hallo @peterle

hab's jetzt nicht getestet, aber eigentlich müsste es so gehen:
Code: 
RewriteEngine on
RewriteRule   ^portal\/archive\/index\.php\/t\-([0-9]{1,6})\.html$       /portal/showthread.php?t=$1 [R=301,L]

Das geht davon aus, dass die Zahl zwischen 1 und 6 Ziffern lang ist ({1,6}). Das müsstest Du ggf. anpassen.

Mit dem R=301 sendet der Apache den HTTP Status Code 301 und gibt damit an, dass sich die URL der Seite permanent geändert hat. Andernfalls könntest Du hier 302 eintragen, um einen temporären Redirect zu machen. Google präferiert 301, wo es Sinn macht.

Das L am Ende steht für "last" und besagt, dass nach dem Matchen dieser Regel Schluss sein soll und keine weitere Regel mehr geprüft werden soll (vergleichbar einem "quick" in pf-Regeln). Auch hier musst Du gucken, ob das in Deinem Fall richtig ist.

Falls zusätzlich noch ein Query-String existieren kann (z.B. .../t-127253.html?irgendwas=123 , müsste der natürlich auch berücksichtigt werden. Im o.g. Code würde der im Redirect einfach weggelassen.
 
Noch ein Nachtrag von mir als Performance-Junkie (was Webseiten betrifft):
  • CSS und JS Dateien werden bei www.hobbyschneiderin24.net alle unkomprimiert versandt. Wenn hier mod_deflate rangelassen würde (wie beim HTML selbst), könnten rund 1,5 von 2,5 MB eingespart werden.
  • CSS und JS Dateien haben nur einen Etag im HTTP-Header aber keinen max-age oder expires Header. Damit muss der Browser (im Prinzip) bei jedem Seitenabruf, den Server für jede solche Datei fragen, ob er etwas anderes hat, als die Datei mit diesem oder jenem Etag. Wenn ein max-age oder expires header vorhanden wäre, würde er diese Frage bis zum fraglichen Datum gar nicht mehr stellen, sondern sofort die Datei aus dem Cache holen (sofern sie dort liegt). Auf dem Desktop mit Breitbandanschluss macht das sicher kaum einen Unterschied. Bei mobiler Nutzung können diese vielen Anfragen aber einen gewaltigen Unterschied ausmachen - vor allem wegen der z.T. hohen Latenzzeit.
 
@SolarCatcher

Das funktioniert völlig reibungslos, Danke!

Die Optimierung ist noch nicht ganz abgeschlossen. Es gab irgendwelches Gedöns bei Invision wegen deflate/gzip, ich weiß aber nicht mehr was. Ich mußte so zwischen Tür und Angel wegen zu starken Alterssorgen des alten VB3 und der Hardware von 2008 umziehen.
Aber Danke für den Hinweis, steht auf der Liste wieder weiter oben.

@KobRheTilla
Auch Dir ein Danke für den Nachtrag. Das dürfte beim Archiv selten sein, aber irgendwer kommt damit um die Ecke.


In 18 Stunden sind jetzt 50.000 404 aufgetreten und ich bin wirklich erstaunt, was für Anfragen da so kommen. Zu jedem von 2.5M Posts scheint es eine Anfrage nach einer Antwort zu geben. Ich vermute mal den Versuch von google einfach jedem Link zu folgen. Mal schauen, was ich noch alles finde.
 
peterle schrieb:
Das funktioniert völlig reibungslos, Danke!
Zum Vergrößern anklicken....
Schön, das freut mich.

peterle schrieb:
Die Optimierung ist noch nicht ganz abgeschlossen. Es gab irgendwelches Gedöns bei Invision wegen deflate/gzip, ich weiß aber nicht mehr was.
Zum Vergrößern anklicken....
Da geht es vermutlich um die BREACH Attack. Da scheint weiterhin sehr unklar zu sein, wie man verwundbare Einstellungen erkennen kann.

Klar ist jedenfalls: Um verwundbar zu sein, müssen mind. 3 Bedingungen zusammenkommen. Eine dieser Bedingungen ist, dass der Response Body User Input widerspiegeln muss (z.B. aus POST- oder GET-Variablen). Daher habe ich beim jüngsten Neu-Einrichten eines Servers die Komprimierung bei allen *.php-Dateien abgestellt, bei allen statischen und gut-komprimierbaren Resourcen aber beibehalten (v.a. CSS, JS). Auf der von Dir betreuten Domain ist es genau umgekehrt: Das (dynamisch generierte) HTML ist gzip-komprimiert. die statischen Stylesheets und JavaScript-Dateien dagegen nicht. Meines Erachtens sollte es - wenn man auf BREACH schaut - genau umgekehrt sein. Ich bin da aber echt kein Experte.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben