Contao 4.4 - Problem mit Seitenalias

Hallo liebe Leute,
heute mal ein Problem aus der Kategorie seltsame Phänomene. Und zwar habe schleppe ich wie denke ich auch einige andere eine Basisinstallation mit mir rum (SQL Daten der 0-8-15 Seiten wie Kontakt, vielen Dank für Ihre Nachricht etc.) Gerade hab ich diese auf eine neue Installation hoch geladen und habe nun bei der Seite Kontakt mit dem Seitenalias kontakt folgendes Problem.
Werde jedesmal beim Aufruf der Seite Kontakt im Frontend zur Home Seite weitergeleitet (404 und 403 wurden vorsichtshalber mal deaktiviert, kommt jedoch auch keine Fehlermeldung), die Einträge in tl_page sehen ebenfalls sauber aus (keine Redirect einträge oder ähnliches). Ändere ich den alias auf z.B: kontaktz ist die Seite wieder problemlos erreichbar. Das neu anlegen einer Seite mit dem alias kontakt bleibt auch ohne Erfolg.

Kurz ich habe echt keine Ahnung wodurch den Aufruf des Alias noch blockiert werden könnte, hat jemand eine Idee?

Hat sich da eine Lösung gefunden? Ich hab das Problem nämlich auch, dass manchmal, nachdem ich eine Seite bearbeitet habe, die Seite "verbrannt" ist, das heißt beim Öffnen wird immer ein 301 Moved permanently (from Disk Cache) ausgelöst und ich lande auf der Home-Page meiner Site. Sobald ich den alias der Seite ändere, ist die Seite wieder erreichbar, aber der ursprüngliche Alias lässt sich ums verrecken nicht mehr öffnen. Ich hab schon alles mögliche unternommen, herauszufinden, wo dieser 301 redirect herkommt, habe das aber nicht herausgefunden.

Ich setze eine aktuelle Contao 4.4 Version ein, als Erweiterung habe ich noch changelanguage installiert, aber die Redirect-Regeln der Erweiterung greifen da nicht, das habe ich schon überprüft.

Irgendjemand muss doch wissen, wo dieses Problem herkommt.

Poste die URL, die zu einem 301 Redirect führt.

So, jetzt hab ich gerade noch mal was anderes problert. Wenn ich die Site im Debug-Modus (mit app_dev.php) laufen lasse, dann öffnet sich die Seite, die sich normalerweise nicht öffnen lässt auch problemlos. Das muss ja dann wohl irgend etwas mit den htaccess-Definitionen zu tun haben, denn nun ist ja nur die URL anders und es befindet sich noch ein app_dev.php vor der eigentlichen URL.

Helmut

Zitat:

---

Zitat von Spooky

Poste die URL, die zu einem 301 Redirect führt.

---

https://www.photosync-app.com/suppor...i-cameras.html

Da kommt kein Redirect:

Code:

---

$ curl -I https://www.photosync-app.com/support/camera/answers/supported-canon-eos-wi-fi-cameras.html
  % Total    % Received % Xferd  Average Speed  Time    Time    Time  Current
                                Dload  Upload  Total  Spent    Left  Speed
  0 27228    0    0    0    0      0      0 --:--:-- --:--:-- --:--:--    0HTTP/1.1 200 OK
Date: Wed, 08 Jan 2020 15:54:00 GMT
Server: Apache/2.4.18 (Ubuntu)
Set-Cookie: PHPSESSID=lfh69nntj6qvsqk2e4q80aqfr8; path=/; httponly
Cache-Control: must-revalidate, no-cache, no-store, private
Vary: Contao-Page-Layout
Contao-Page-Layout: desktop
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer-when-downgrade, strict-origin-when-cross-origin
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Content-Length: 27228
Age: 0
Expires: Wed, 08 Jan 2020 15:54:00 GMT
Content-Type: text/html; charset=utf-8

---

Zitat:

---

Zitat von Spooky

Da kommt kein Redirect:

Code:

---

$ curl -I https://www.photosync-app.com/support/camera/answers/supported-canon-eos-wi-fi-cameras.html
  % Total    % Received % Xferd  Average Speed  Time    Time    Time  Current
                                Dload  Upload  Total  Spent    Left  Speed
  0 27228    0    0    0    0      0      0 --:--:-- --:--:-- --:--:--    0HTTP/1.1 200 OK
Date: Wed, 08 Jan 2020 15:54:00 GMT
Server: Apache/2.4.18 (Ubuntu)
Set-Cookie: PHPSESSID=lfh69nntj6qvsqk2e4q80aqfr8; path=/; httponly
Cache-Control: must-revalidate, no-cache, no-store, private
Vary: Contao-Page-Layout
Contao-Page-Layout: desktop
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer-when-downgrade, strict-origin-when-cross-origin
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Content-Length: 27228
Age: 0
Expires: Wed, 08 Jan 2020 15:54:00 GMT
Content-Type: text/html; charset=utf-8

---

---

Ich hab's ja auch immer für ein Cache-Problem gehalten, mit cURL ist es tatsächlich so, dass nix passiert, aber es muss ein Caching Problem sein, das durch Contao oder die Contao-Konfiguration ausgelöst wird, ich hab das sonst mit keiner anderen Website. In meinem Chrome krieg ich immer den Redirect und das ändert auch nichts, wenn ich den Cache lösche. Das Problem hab ich auch mit dem Safari unter iOS. Da konnte ich es eben aber tatsächlich in den Griff bekommen, indem ich alle Webseitendaten gelöscht habe, also alles, was wohl lokal über die Seite abgelegt ist.

Aus irgend einem Grund bekommen die Browser ja wohl suggeriert, dass sie einen 301 redirect machen sollen.

Anhang 23044

Hast du in deinem reichen Erfahrungsschatz schon von solchen Problemen gehört?

Hmm, in meinem Chrome sehe ich da einen 200 und sonst nix (analytics mal ausgenommen) ...

Zitat:

---

Zitat von hschottm

Ich hab's ja auch immer für ein Cache-Problem gehalten, mit cURL ist es tatsächlich so, dass nix passiert, aber es muss ein Caching Problem sein, das durch Contao oder die Contao-Konfiguration ausgelöst wird, ich hab das sonst mit keiner anderen Website. In meinem Chrome krieg ich immer den Redirect und das ändert auch nichts, wenn ich den Cache lösche. Das Problem hab ich auch mit dem Safari unter iOS. Da konnte ich es eben aber tatsächlich in den Griff bekommen, indem ich alle Webseitendaten gelöscht habe, also alles, was wohl lokal über die Seite abgelegt ist.

Aus irgend einem Grund bekommen die Browser ja wohl suggeriert, dass sie einen 301 redirect machen sollen.

Anhang 23044

Hast du in deinem reichen Erfahrungsschatz schon von solchen Problemen gehört?

---

Hast du denn deinen Browser Cache schon gelöscht, oder nicht? 301 Redirects werden vom Browser für immer gecached (weil sie ja permanent sind).

Zitat:

---

Zitat von Spooky

Hast du denn deinen Browser Cache schon gelöscht, oder nicht? 301 Redirects werden vom Browser für immer gecached (weil sie ja permanent sind).

---

Yep, Chrome, Browserdaten löschen, Bilder und Dateien im Cache. Hilft nix. Bei Safari unter iOS hilft das.
Es ist definitiv ein Caching-Problem, das ist mir jetzt klar, bloß scheint dieses aggressive Caching ja wohl durch Änderungen auf den Seiten ausgelöst zu werden und das offenbar auch nur manchmal. Ich traue mich halt schon gar nicht mehr, Content zu barbeiten, weil das immer mal wieder dazu führen kann, dass sich die Seite nicht mehr öffnet und das ist natürlich bei einer FAQ-Seite für die Kunden ganz schön Kacke.

Ich habe dieses Phänomen auch erst seit ich Contao 4.4 einsetze, vorher habe ich das nie gehabt. Weder mit 2.x noch mit 3.x

Nimmt Contao denn irgendwie auf die Caching-Strategien des Browsers Einfluss?

Mich treibt dieses Verhalten schon seit Monaten in den Wahnsinn. Ich kann ja unseren Kunden, nur weil ich eine FAQ-Seite geändert habe nicht sagen, dass sie ihren Browsercache leeren sollen, damit die Seite wieder angezeigt wird und der ursprüngliche Autor dieses Threads scheint ja ein identisches Problem gehabt zu haben.

Wie sieht denn Deine aktuelle web/.htaccess aus?

Zitat:

---

Zitat von xchs

Wie sieht denn Deine aktuelle web/.htaccess aus?

---

Das müsste unverändert sein, da hab ich glaub ich nie was gemacht:

Code:

---

<IfModule mod_headers.c>
    # Allow access from all domains for webfonts (see contao/core-bundle#528)
    <FilesMatch "\.(ttf|ttc|otf|eot|woff2?|font\.css)$">
        Header set Access-Control-Allow-Origin "*"
    </FilesMatch>
</IfModule>

<IfModule mod_rewrite.c>

    RewriteEngine On

    # Determine the RewriteBase automatically and set it as environment variable.
    # If you are using Apache aliases to do mass virtual hosting or installed the
    # project in a subdirectory, the base path will be prepended to allow proper
    # resolution of the app.php file and to redirect to the correct URI. It will
    # work in environments without path prefix as well, providing a safe, one-size
    # fits all solution. But as you do not need it in this case, you can comment
    # the following 2 lines to eliminate the overhead.
    RewriteCond %{REQUEST_URI}::$1 ^(/.+)/(.*)::\2$
    RewriteRule ^(.*) - [E=BASE:%1]

    # Sets the HTTP_AUTHORIZATION header removed by Apache
    RewriteCond %{HTTP:Authorization} .
    RewriteRule ^ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    # Redirect to URI without front controller to prevent duplicate content
    # (with and without `/app.php`). Only do this redirect on the initial
    # rewrite by Apache and not on subsequent cycles. Otherwise we would get an
    # endless redirect loop (request -> rewrite to front controller ->
    # redirect -> request -> ...).
    # So in case you get a "too many redirects" error or you always get redirected
    # to the start page because your Apache does not expose the REDIRECT_STATUS
    # environment variable, you have 2 choices:
    # - disable this feature by commenting the following 2 lines or
    # - use Apache >= 2.3.9 and replace all L flags by END flags and remove the
    #  following RewriteCond (best solution)
    RewriteCond %{ENV:REDIRECT_STATUS} ^$
    RewriteRule ^app\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]

    # If the requested filename exists, simply serve it.
    # We only want to let Apache serve files and not directories.
    RewriteCond %{REQUEST_FILENAME} -f
    RewriteRule ^ - [L]

    # Rewrite all other queries to the front controller.
    RewriteRule ^ %{ENV:BASE}/app.php [L]
</IfModule>

<IfModule !mod_rewrite.c>
    <IfModule mod_alias.c>
        # When mod_rewrite is not available, we instruct a temporary redirect of
        # the start page to the front controller explicitly so that the website
        # and the generated links can still be used.
        RedirectMatch 302 ^/$ /app.php/
        # RedirectTemp cannot be used instead
    </IfModule>
</IfModule>

---

Wie schauen denn Deine Cache-Einstellungen im Startpunkt einer Webseite (bzw. in den Einstellungen der betreffenden Seite) aus?

Ich habe zwar solche Probleme noch nie gehabt, habe aber das Gefühl, dass das Caching-Verhalten der Browser irgendwie aggressiver geworden ist. Es muss also nicht zwingend mit Änderungen in Contao zusammenhängen.

Zitat:

---

Zitat von xchs

Wie schauen denn Deine Cache-Einstellungen im Startpunkt einer Webseite (bzw. in den Einstellungen der betreffenden Seite) aus?

---

Da hab ich nie was eingestellt. Die Seite selbst wird ja eh immer unterschiedlich über den FAQ-Reader befüllt, also automatisch generiert. Und in der Site hab ich keine Cache-Einstellungen gesetzt. Ich kann natürlich mal probieren, dass kein Cache genommen werden soll.

Auf die Idee bin ich noch gar nicht gekommen.

Ich hab jetzt in Chrome zusätzlich noch mal die Website-Einstellungen und die Cookies gelöscht und dann konnte ich die Seite auch wieder öffnen. Eventuell ist das wirklich nur aggressiveres Caching der Browser. Ist halt total schräg, dass der Browser da eine 301-Weiterleitung auf die Home-Seite einrichtet, ich frag mich halt, wo die herkommt.

Ich danke euch erst mal für euer umfangreiches Feedback und werde die ganze Sache noch mal weiter beobachten. Vielleicht ist es wirklich nur Zufall, dass es gerade im Zusammenhang mit Contao auftritt.