lspreee: 301 weiterleitung klientseitig verhindern

Hallo,

<background>
ich benutze ModRewrite. Wenn kein Script angegeben ist oder das Script nicht existiert, wird index.php angenommen.

Anschliessend wird aber noch mittels php das Script und die Page auf Existenz überprüft (DB). Falls die aufgerufene Seite ins Leere führt, wird per 301 weitergeleitet. ~~~php

header("HTTP/1.1 301 Moved Permanently");

  
Das habe ich gemacht, damit die falsche Adresse nicht stehen bleibt. Ist das ok so?  
</background>  
  
Gibt es nun eine Möglichkeit, dass der Klient die 301 Weiterleitung deaktiviert? In diesem Fall, würde er bei mir auch nicht weiterkommen.  
Ich habe in meinem Web Developer unter Disable "disable meta redirects" aktiviert, doch es geht immer noch.  
  
Wenn es mit einfachen Mitteln möglich ist, würde ich aus kosmetischen Gründen noch etwas für diese Möglichkeit einbauen (irgendeine Anzeige). Wenn es nicht oder nur sehr schwer geht, würde ich es mir sparen.  
  
Vielen Dank für 
  1. Gibt es nun eine Möglichkeit, dass der Klient die 301 Weiterleitung deaktiviert?

    Sicher geht das - es gibt eine Masse an erweiterungen oder Einstellungsmöglichkeiten, die nach jedem empfangenen HTTP-Response oder vor jedem Request eine entsprechende Interaktion des Benutzers verlangen.

    Tamper Data für Firefox ist z.B. eine Möglichkeit. Alternativ kann man auch Network.http.redirection-limit auf 0 setzen.

    Unter Opera geht das mit Client Pull bzw. Client Refresh.

    In diesem Fall, würde er bei mir auch nicht weiterkommen.

    Sicher, aber manuell - opera bietet in diesem Fall einen Link an, um der Weiterleitung manuell zu folgen.

    Ich habe in meinem Web Developer unter Disable "disable meta redirects" aktiviert, doch es geht immer noch.

    Das ist etwas anderes.

    Wenn es mit einfachen Mitteln möglich ist, würde ich aus kosmetischen Gründen noch etwas für diese Möglichkeit einbauen (irgendeine Anzeige).

    Sende einfach einen Message Body bei deinem Redirect mit - falls der Browser gutmütig ist, zeigt er diesen auch an.

    Wenn es nicht oder nur sehr schwer geht, würde ich es mir sparen.

    Ordentliche Browser bieten selbst einen Link auf die Zielseite an - wer Redirects deaktiviert, weiß auch wie man mit diesem Problem umgehen muss. Ich denke, da muss du keinen Aufwand betreiben.

    Du solltest dich eher Fragen, ob die Weiterleitung überhaupt notwendig bzw. sinnvoll ist. Wenn jemand "kein Script angibt", was auch immer das jetzt bedeuten mag - sollte er eine Fehlermeldung erhalten. 400 Bad Request wäre wesentlich sinnvoller an dieser Stelle.

    1. Vielen Dank für diese wertvollen Tipps.

      Du solltest dich eher Fragen, ob die Weiterleitung überhaupt notwendig bzw. sinnvoll ist. Wenn jemand "kein Script angibt", was auch immer das jetzt bedeuten mag - sollte er eine Fehlermeldung erhalten. 400 Bad Request wäre wesentlich sinnvoller an dieser Stelle.

      mit Script meine ich die tatsächlich aufgerufenen php-Scripts, "index.php". Diese sind bei mir spärlich, bislang gibt es nur zwei. Der Rest geht über url-Parameter ("/user/sowienoch" + ModRewrite).

      Du hast Recht, für gewisse Fehler auf der Seite, wie Seite nicht vorhanden, wäre es gut einen passenderen Header zu senden.
      Vielen Dank für den Hinweis.

      SUPER!!!

    2. Hi,

      Du solltest dich eher Fragen, ob die Weiterleitung überhaupt notwendig bzw. sinnvoll ist. Wenn jemand "kein Script angibt", was auch immer das jetzt bedeuten mag - sollte er eine Fehlermeldung erhalten. 400 Bad Request wäre wesentlich sinnvoller an dieser Stelle.

      Nein, eher nicht. „Kein Script angeben“ bedeutet vermutlich Zugriff auf eine nicht existente Ressource. Das ist ein Fall für einen 404 oder 410 - aber kein Grund, an der (HTTP-)Syntax der Anfrage herum zu mäkeln, was der 400 täte.

      MfG ChrisB

      --
      RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
      1. Nein, eher nicht. „Kein Script angeben“ bedeutet vermutlich Zugriff auf eine nicht existente Ressource. Das ist ein Fall für einen 404 oder 410 - aber kein Grund, an der (HTTP-)Syntax der Anfrage herum zu mäkeln, was der 400 täte.

        Das kommt darauf an - wenn "Kunde" selbst am Link herumspielt und anstatt index.php?script=meintollesscript einfach mal index.php?script=irgendeinscript aufruft, obwohl in der API-Dokumentation klar steht dass es "meintollesscript" und "ganzeinanderesscript" gibt, dann ist das klar ein Syntaxfehler und selbstvertändlich mit einem 4xx zu behandeln.

        Ob das nun ein 400 oder 404 ist, ist eine Einzelfallentscheidung - ein 410 wäre sinnvoll, wenn die Methode/das Script in einer alten Version der API existiert hat und entfernt wurde.

        1. Ob das nun ein 400 oder 404 ist, ist eine Einzelfallentscheidung - ein 410 wäre sinnvoll, wenn die Methode/das Script in einer alten Version der API existiert hat und entfernt wurde.

          Mein Fehler - du hast natürlich recht. Bad Request bezieht sich ausschließlich auf HTTP-Syntax-Fehler.