Apache Umstellung Februar 2015 und Default-.htaccess von Contao

[tofo]

Hallo,

ich habe leider die unliebsame Erfahrung mit Domainfactory gemacht, dass nach deren Apache-Update eine meiner Webseiten, die ich noch mit Contao 2.11.17 betreibe, nicht mehr erreichbar war, weil ein Error 500 angezeigt wurde. Grund ist eine Umstellung in der Behandlung von mod_filter, welche ich übersehen habe.

Ein Auszug aus der Default-.htaccess sieht so aus:

<IfModule filter_module>
   FilterDeclare   COMPRESS
   FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/html
   FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/css
   FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/plain
   FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/xml
   FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/x-component
   FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/javascript
   FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/json
   FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/xml
   FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/xhtml+xml
   FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/rss+xml
   FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/atom+xml
   FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/vnd.ms-fontobject
   FilterProvider  COMPRESS  DEFLATE resp=Content-Type $image/svg+xml
   FilterProvider  COMPRESS  DEFLATE resp=Content-Type $image/x-icon
   FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/x-font-ttf
   FilterProvider  COMPRESS  DEFLATE resp=Content-Type $font/opentype
   FilterChain     COMPRESS
   FilterProtocol  COMPRESS  DEFLATE change=yes;byteranges=no
 </IfModule>

Aussage von Domainfactory:

=========
mod_filter:
=========

Die Syntax bei "mod_filter: FilterProvider" wurde geändert und verwendet nun einen booleschen Ausdruck, ob ein Filter angewendet wird.

So muss z.B. aus FilterProvider COMPRESS DEFLATE resp=Content-Type $text/html  der neue Eintrag  FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} = 'text/html'" werden.

Nur falls sich wer wundert, dass seine Webseite ebenfalls nicht mehr erreichbar ist.

Gruß, Thomas

[lucina]

Siehe https://gist.github.com/kikmedia/b5a4a647b996a3edadb3

[planepix]

…und Carolina hat auch schon was auf GIST dazu. Danke.
https://twitter.com/carolinakoehn/st...64072261619712

[tofo]

Ich nehme an, dass ich in der .htaccess lediglich die betroffenen Module entsprechend dem Ticket in Git anpassen muss.

Gruß, Thomas

[lucina]

Im Prinzip ja. Wirf die entsprechenden Stellen raus (oder kommentiere sie aus) und füge die neuen Direktiven ein.

[tofo]

Gesagt, getan, verifiziert, schnurrt wie ein Kätzchen.

[the_scrat]

Danke für die Info, habs auch "bemerkt". Ne Multidomain-Installation mit 30 Domains einfach mal alle auf Error 500.... so fängt der Tag gut an
Hab einfach auf die Schnelle die .htaccess von ner Contao 3.4 Installation genommen, die tats auch.

[gregor]

Habe nach der Apache-Aktualisierung mit einer Contao 3.2.19 Installation trotz korrekter .htaccess-Datei Probleme mit einer Erweiterung gehabt.

Die im Erweiterungsordner assets vorhandene CSS-Datei wurde nicht geladen. Nachdem ich die im asset-Ordner vorhandene .htaccess von

order deny,allow
deny from all

in

<IfModule !mod_authz_core.c>
  Order allow,deny
  Allow from all
</IfModule>
<IfModule mod_authz_core.c>
  Require all granted
</IfModule>

geändert habe, wurde die CSS-Datei wieder geladen.

Da bei mir in weiteren, für Contao 3.2.x freigegebenen Erweiterungen .htaccess-Daten mit "alter" Syntax vorhanden sind, bedeutet dies nun, dass diese alle manuell aktualisiert werden müssen?

Vielen Dank für eine kurze Aufklärung.

LG
Gregor

[lucina]

Das wäre aus meiner Sicht eine Sache der Erweiterung. Wenn die für ein altes Contao 2.x nicht mehr angepasst wird, dann musst Du es vermutlich selbst tun, ja.

[gregor]

Es geht ausschließlich um Contao 3.2.19 und aktuelle Erweiterung wie Multicolumnwizzard, Simple_Columns, Botdetection usw., wo sich der alte Syntax in verschiedenen .htaccess-Datei befindet.

Also erstmal manuell korrigieren und Ticket bei der jeweiligen Erweiterung aufmachen.

LG
Gregor

[Thomas]

Es gibt für den Häuptling ein Modul welches die abwärts Kompatibilität gewährleisten soll!
Ich komme gerade nur nicht auf die Bezeichnung.
Betrifft ja auch nur Apache >=2.4.

[BugBuster]

Botdetection? Hat die neue htaccess schon lange dabei, seit Version 3.1.0 vom 19. Juni 2013


Und das Apache Modul nennt sich: mod_access_compat

[gregor]

Hm,
bei mir liegt so eine in botdetection/languages/ru/ rum, datiert auf den 18.05.2014.
Weiß nun auch nicht wie die da reingekommen ist.

Da in den anderen Sprachordnern keine .htacess vorhanden ist, kann ich die da sicherlich löschen.

LG
Gregor

[BugBuster]

Ach, aus dem alten ER2. Guter Hinweis, da liegt es noch historisch drin, werd ich mal rauslöschen, ist ja überflüssig mittlerweile.

[chaela]

Siehe https://gist.github.com/kikmedia/b5a4a647b996a3edadb3

Danke dafür. Hat mir sehr geholfen.
Da kommt man vom Feierabend heim und das erste was man liest ist, dass die eigene Homepage nicht mehr erreichbar ist.
Und das wo df.eu extra in der Mail betonte, dass die Webseiten trotz Umstellung erreichbar bleiben.

[MacKP]

Und das wo df.eu extra in der Mail betonte, dass die Webseiten trotz Umstellung erreichbar bleiben.

Naja, erreichbar wars ja im Grunde. df.eu kann ja auch nichts dafür, wenn da uralt htaccess-Dateien das ganze verhindern. Deswegen sollte man sich solche Termine immer markieren und dann mal nachschauen ob noch alles geht. Die Mail von denen bekommt man ja früh genug, damit man sich darauf vorbereiten kann ;-)

Viele Grüße