FasterFox und das böse precaching

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • FasterFox und das böse precaching

    Hi,

    ich wollte mal eure Meinung hören. Auf verschiedenen Pages von mir werden Aktionen über einen Link ausgeführt.

    Bsp:
    PHP-Code:
    <a href="del-entry_13.html" onclick="return confirm('Wirklich?');">
      
    Lösche Eintrag
    </a
    Vorteil von dieser Lösung es funktioniert auch noch ordentlich wenn JavaScript aus ist. Den Komfort einer Nachfrage hat man dann eben nicht, aber das ist der Kompromiss. Soweit auch kein Problem.

    Nun gibt es aber den "bösen" FasterFox der agressives Prefetching veranstaltet.
    Gehen wir zum Beispiel mal von einem Gästebuch aus, das man sich als Administrator anschaut. Der Administrator hat über o.g. Link die Möglichkeit diverse Einträge zu löschen. FasterFox folgt ja nun jeden Link und löscht dadurch "alle" Einträge.

    Eine Möglichkeit ist das unterbinden der eigentlichen Löschaktion durch Abfrage des Headers den FasterFox mitsendet.
    PHP-Code:
    if (!isset($_SERVER['HTTP_X_MOZ']) OR
        (isset(
    $_SERVER['HTTP_X_MOZ']) AND 
        
    $_SERVER['HTTP_X_MOZ'] != 'prefetch')) {
      
    //führe Löschaktion aus

    Eine andere Möglichkeit besteht darin, alle Anfragen von FasterFox mit mod_rewrite umzuleiten.

    Code:
    RewriteCond %{HTTP:X-moz} ^prefetch$
    RewriteRule ...
    Nun meine Frage: Wie würdet ihr mit der Problematik umgehen? Wo sollte man die Requests von FasterFox hin umleiten?
    Ein paar Kommentare von euch zu dem Thema würden mich freuen.

  • #2
    Hi,

    es gibt auch noch andere tools die das auf ähnliche weise machen.

    Es gibt eine einfache regel. "Put destructive actions behind a post-request".
    Das ist meiner meinung nach die beste methode.


    greets
    (((call/cc call/cc) (lambda (x) x)) "Scheme just rocks! and Ruby is magic!")

    Kommentar


    • #3
      Es steht glaub ich sogar irgendwo im HTTP RFC, dass GET-Requests keine Daten an den Server schicken sollen, der dadurch dann was verändert.

      Also einfach ein kleines Formular machen, das das ganze per POST abschickt.
      hopka.net!

      Kommentar


      • #4
        Nunja, das ist richtig. Ich denke in den meisten Fällen ist es auch sinnvoll. Momentan begnüge ich mich mit den aufgezeigten Lösungen.

        Nur macht es doch keine Sinn (oder doch?) z.B. bei einer administrativen Liste von Gästebuch-einträge (oder was auch immer) jeden Eintrag mit einem Formular zu versehen.
        Vielleicht muß ich umdenken, aber gibt es nicht genügen Beispiel für solch ein vorgehen?

        Kommentar


        • #5
          Original geschrieben von prego
          Nur macht es doch keine Sinn (oder doch?) z.B. bei einer administrativen Liste von Gästebuch-einträge (oder was auch immer) jeden Eintrag mit einem Formular zu versehen.
          Wenn du nicht willst, dass spider oder clientseitige precaching engines
          dein gb leer räumen, dann schon.

          Original geschrieben von prego
          Vielleicht muß ich umdenken, aber gibt es nicht genügen Beispiel für solch ein vorgehen?
          Es gibt auch genug beispiele für jede menge andere schlechte
          angewohnheiten. Das bedeutet nicht, dass es das richtige vorgehen
          ist. Bei deiner momentanen vorgehensweise müsstest du
          für jedes tool, dass auf dem client läuft und precaching betreibt
          einen weg finden es zu identifizieren und darauf zu reagieren.
          Benutzt du dagen die "best practice" bist du auf einen schlag deine
          probleme los.


          greets
          (((call/cc call/cc) (lambda (x) x)) "Scheme just rocks! and Ruby is magic!")

          Kommentar


          • #6
            Ok, da habt ihr wohl recht. Also "best practice" aneignen...

            Danke.

            Kommentar

            Lädt...
            X