Simon: Post-Daten nach 404-Redirect behalten

Ich habe ein kleines Problem. Ich habe auf meiner Seite eine .htacces-Datei angelegt, die beschreibt dass, falls die gesuchte Seite nicht existiert, eine eigene 404-Nachricht ausgibt. Und zwar leitet sie zu der Datei 404.php weiter. Bei dieser Weiterleitung gehen aber alle Post-Daten verloren, die eigentlich an die (nicht gefundene) Seite gehen sollten, welche ich aber in 404.php gerne verarbeiten möchte. Wie mache ich das?

Meine .htaccess-Datei sieht etwa so aus:
#-----
ErrorDocument 404 /404.php
#-----

  1. hi,

    Meine .htaccess-Datei sieht etwa so aus:
    #-----
    ErrorDocument 404 /404.php
    #-----

    Ok, schauen wir mal wie das so abläuft. Der Request sieht so aus:

    #---
    POST /unreacheable.url HTTP/1.1
    Host: $host
    Content-Type: application/x-www-urlencoded
    Content-Length: $len
    Connection: close

    $content
    #---

    /unreacheable.url gibt es nicht auf dem Server, der wirft einen 404 und zieht Dein Script 404.php an.

    Der $content ist serverseitig in STDIN zu finden. Falls es mit PHP die Möglichkeit gibt, STDIN auszulesen (Dein Script 404.php), kommst Du damit an die POST-Daten. Mit Perl funktioniert das einwandfrei, hab ich grad ebend getestet.

    Hotti

    1. hi,

      Meine .htaccess-Datei sieht etwa so aus:
      #-----
      ErrorDocument 404 /404.php
      #-----

      Ok, schauen wir mal wie das so abläuft. Der Request sieht so aus:

      #---
      POST /unreacheable.url HTTP/1.1
      Host: $host
      Content-Type: application/x-www-urlencoded
      Content-Length: $len
      Connection: close

      $content
      #---

      /unreacheable.url gibt es nicht auf dem Server, der wirft einen 404 und zieht Dein Script 404.php an.

      Der $content ist serverseitig in STDIN zu finden. Falls es mit PHP die Möglichkeit gibt, STDIN auszulesen (Dein Script 404.php), kommst Du damit an die POST-Daten. Mit Perl funktioniert das einwandfrei, hab ich grad ebend getestet.

      Hotti

      Ok, das klingt sehr interessant, aber nun habe ich kein Plan, was STDIN ist bzw. wie ich in PHP überhaupt darauf zugreife.

      Was ich übrigens eigentlich bezwecken wollte ist folgendes, wozu ich erst auch ein zweites Thema starten wollte: Wer Wikipedia kennt, der weiß bestimmt, dass in der Adresse zum Beispiel "...de/Wikipedia:Hauptseite" stehen kann. "Wikipedia:Hauptseite" kann aber keine existierende Seite auf dem Server sein, weil es einen Doppelpunkt enthält, was soweit ich weiß in Dateinamen nicht erlaubt ist. Außerdem ist auch eine Adresse wie "...de//" problemlos möglich.
      Ich habe herausgefunden, dass ich sowas mit einem 404-"Redirect" machen könnte, wo PHP dann die Adresse oben auslesen und auswerten kann. Nur da fehlen mir leider die POST-Daten.
      Es ist zwar jetzt Off-Topic, aber falls jemand weiß, wie man sowas wie in Wikipedia macht, wäre mein Problem eigentlich auch schon gelöst. Übrigens: Ich weiß, dass für spezielle Seiten (zum Beispiel zum Bearbeiten) bei Wikipedia eine "richtige" Adresse wie "/index.php" verwendet wird. Möglicherweise machen sie das auch mit 404, doch das konnte ich bisher nicht herausfinden.

      1. Moin Moin!

        Ok, das klingt sehr interessant, aber nun habe ich kein Plan, was STDIN ist bzw. wie ich in PHP überhaupt darauf zugreife.

        <textadventure>Benutze STDIN mit Google</textadventure>

        Was ich übrigens eigentlich bezwecken wollte ist folgendes, wozu ich erst auch ein zweites Thema starten wollte: Wer Wikipedia kennt, der weiß bestimmt, dass in der Adresse zum Beispiel "...de/Wikipedia:Hauptseite" stehen kann.

        Richtig, die vollständige URL ist http://de.wikipedia.org/wiki/Wikipedia:Hauptseite

        "Wikipedia:Hauptseite" kann aber keine existierende Seite auf dem Server sein,

        Warum nicht? Bekommst Du unter der URL eine 404-Seite?

        Natürlich nicht. Die Seite existiert auf dem Server, und sie wird Dir mit Status 200 OK ausgeliefert.

        weil es einen Doppelpunkt enthält, was soweit ich weiß in Dateinamen nicht erlaubt ist.

        Natürlich sind Doppelpunkte in Dateinamen erlaubt. Einige Krüppel-Betriebssysteme vertragen keine Doppelpunkte in Dateinamen, aber deswegen sind sie nicht generell verboten.

        Aber was haben Dateinamen mit der genannten URL der Wikipedia zu tun?

        Richtig, absolut GAR NICHTS! Die Seiten, die Du in der Oberfläche der Wikipedia siehst, stammen nahezu zu 100% aus einer (MySQL?-)Datenbank.

        Außerdem ist auch eine Adresse wie "...de//" problemlos möglich.

        Ja und? Nach dem ersten Slash nach dem Hostnamen ist in der URL so ziemlich alles erlaubt. Wenn Du einen lustigen Tag hast, kannst Du dort Slashes, Backslashes und sonstige wirre Zeichen lagern, wie Du lustig bist, und für jede Kombination eine andere Seite ausliefern.

        Ich habe herausgefunden, dass ich sowas mit einem 404-"Redirect" machen könnte, wo PHP dann die Adresse oben auslesen und auswerten kann. Nur da fehlen mir leider die POST-Daten.

        Großer Mumpitz. Sieh Dir die URL nochmal genau an. Was steht zwischen "http://de.wikipedia.org/" und "Wikipedia:Hauptseite?"

        Richtig, da steht "wiki/". Oder genauer: "wiki" und "/".

        Und das ist so ziemlich das ganze Geheimnis dahinter.

        Es ist zwar jetzt Off-Topic, aber falls jemand weiß, wie man sowas wie in Wikipedia macht, wäre mein Problem eigentlich auch schon gelöst. Übrigens: Ich weiß, dass für spezielle Seiten (zum Beispiel zum Bearbeiten) bei Wikipedia eine "richtige" Adresse wie "/index.php" verwendet wird. Möglicherweise machen sie das auch mit 404, doch das konnte ich bisher nicht herausfinden.

        Nein, auch das geht ohne 404, mit der gleichen Technik.

        <textadventure>Benutze Google mit PATH_INFO</textadventure>.

        Der Webserver zerlegt die URL bis /wiki und mappt diese URL auf ein Programm. Das kann ein CGI sein, ein PHP-Script, oder etwas völlig anderes. Aber der Webserver kennt es (aufgrund seiner Konfiguration) und weiss, dass alles, was auf /wiki folgt, nicht mehr für ihn, sondern für das Programm bestimmt ist. Dem Programm wird nun der Rest der URL in ein bis zwei Häppchen übermittelt, bei CGIs und PHP als PATH_INFO und QUERY_STRING, außerdem wird oft noch die komplette angeforderte URL mit übergeben (REQUEST_URI). Das Programm hat dann in aller Regel nichts besseres zu tun, als diese Daten weiter zu zerlegen, auf irgendeine Art und Weise (d.h. Datenbank-Abfrage) den passenden Inhalt zu finden, und ggf. noch hübsch in ein HTML-Grundgerüst (Template) verpackt wieder auszuliefern.

        Zum Üben mal ein hoch eindrucksvolles Beispiel, als Perl-Programm. Packe es auf einen geeigneten Webserver so, dass es als /cgi-bin/hallo.cgi erreichbar ist, mache es mit chmod +x ausführbar, und rufe es mit verschiedenen URLs auf:

        http://webserver/cgi-bin/hallo.cgi
        http://webserver/cgi-bin/hallo.cgi/Peter
        http://webserver/cgi-bin/hallo.cgi/Hans
        http://webserver/cgi-bin/hallo.cgi/Franz/Meier
        http://webserver/cgi-bin/hallo.cgi/Osterhase

          
        #!/usr/bin/perl  
        use strict;  
        use warnings;  
          
        my $name=$ENV{'PATH_INFO'}||'Welt';  
        $name=~tr|/| |;  
        print "Content-Type: text/plain\r\n\r\nHallo $name!\n";  
        
        

        Keine Datei Peter, keine Datei Hans, keine Datei Franz/Meier, keine Datei Osterhase, und kein 404. Und trotzdem bekommst Du abhängig von der URL eine individuelle Begrüßung.

        Auch Doppelpunkte funktionieren, wenn auch mit einer selten dämlichen Ausgabe: http://webserver/cgi-bin/hallo.cgi/Dop:pel:punk:te/sind/toll

        Der Code hinter der Wikipedia ist "geringfügig" komplexer, aber er nutzt das gleiche Prinzip.

        Übrigens wäre sogar der Prefix /wiki unnötig, man könnte gängige Webserver auch so konfigurieren, dass sie ALLE Requests an ein solches Programm weiterreichen. Das macht man aber deswegen nicht, weil Webserver in aller Regel statische Dateien wie Stylesheets, Javascripte und Bilder wesentlich effizienter ausliefern können als ein derart gestartetes Programm es könnte, und man läßt sich deswegen ein "Schlupfloch" mit einem anderen URL-Prefix, der auf ein ganz normales Verzeichnis gemappt ist. Dort werden Dateien dann stumpf aus dem Dateisystem ausgeliefert.

        Alexander

        --
        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
        1. "Wikipedia:Hauptseite" kann aber keine existierende Seite auf dem Server sein,

          Warum nicht? Bekommst Du unter der URL eine 404-Seite?

          Natürlich nicht. Die Seite existiert auf dem Server, und sie wird Dir mit Status 200 OK ausgeliefert.

          weil es einen Doppelpunkt enthält, was soweit ich weiß in Dateinamen nicht erlaubt ist.

          Natürlich sind Doppelpunkte in Dateinamen erlaubt. Einige Krüppel-Betriebssysteme vertragen keine Doppelpunkte in Dateinamen, aber deswegen sind sie nicht generell verboten.

          Aber was haben Dateinamen mit der genannten URL der Wikipedia zu tun?

          Richtig, absolut GAR NICHTS! Die Seiten, die Du in der Oberfläche der Wikipedia siehst, stammen nahezu zu 100% aus einer (MySQL?-)Datenbank.

          Das ist mir schon klar gewesen, dass dann keine Datei existiert, die den angegebenen Namen hat. Ich habe mich nur gewundert, weil nach meiner Erfahrung alles nach dem ersten Slash (...de/) nur ein Dateiname sei. Es war mir nicht klar, dass man sowas "umkonfigurieren" kann, dass der Server nicht zwingend nach einer Datei zum ausgeben sucht sondern man eigene Skripts, die unter Umständen immer automatisch ausgeführt werden, egal was der Benutzer oben eingibt.

          Zum Üben mal ein hoch eindrucksvolles Beispiel, als Perl-Programm. Packe es auf einen geeigneten Webserver so, dass es als /cgi-bin/hallo.cgi erreichbar ist, mache es mit chmod +x ausführbar, und rufe es mit verschiedenen URLs auf:

          http://webserver/cgi-bin/hallo.cgi
          http://webserver/cgi-bin/hallo.cgi/Peter
          http://webserver/cgi-bin/hallo.cgi/Hans
          http://webserver/cgi-bin/hallo.cgi/Franz/Meier
          http://webserver/cgi-bin/hallo.cgi/Osterhase

          #!/usr/bin/perl
          use strict;
          use warnings;

          my $name=$ENV{'PATH_INFO'}||'Welt';
          $name=~tr|/| |;
          print "Content-Type: text/plain\r\n\r\nHallo $name!\n";

          
          >   
          > Keine Datei Peter, keine Datei Hans, keine Datei Franz/Meier, keine Datei Osterhase, und kein 404. Und trotzdem bekommst Du abhängig von der URL eine individuelle Begrüßung.  
          >   
          > Auch Doppelpunkte funktionieren, wenn auch mit einer selten dämlichen Ausgabe: http://webserver/cgi-bin/hallo.cgi/Dop:pel:punk:te/sind/toll  
          >   
          > Der Code hinter der Wikipedia ist "geringfügig" komplexer, aber er nutzt das gleiche Prinzip.  
          >   
          
          Immerhin kenne ich jetzt das Prinzip :) Nur leider Benutze ich einen kostenlosen Webhost, bei dem ich keine eigenen CGI Scripts oder Perl habe (aber PHP). Gibt es da einen "allgemeinen" Weg, wie ich mir meinen Server so konfiguriere, damit ich mein Zeil habe (vielleicht mit einer .htaccess-Datei?)?
          
          1. Moin Moin!

            Immerhin kenne ich jetzt das Prinzip :) Nur leider Benutze ich einen kostenlosen Webhost, bei dem ich keine eigenen CGI Scripts oder Perl habe (aber PHP). Gibt es da einen "allgemeinen" Weg, wie ich mir meinen Server so konfiguriere, damit ich mein Zeil habe (vielleicht mit einer .htaccess-Datei?)?

            Der Server dürfte bereits (fast) passend konfiguriert sein, mit dem kleinen Haken, dass Du mit ".php/" in der URL leben mußt.

            Ausprobieren kannst Du das ganz leicht. Lege eine PHP-Datei auf ähnlich hohem Niveau wie mein Perl-Script an, z.B. so, dass sie unter http://dein.web.server/hallo.php erreichbar ist. Die Informationen aus PATH_INFO findest Du $_SERVER['PATH_INFO'] bzw. $_SERVER['ORIG_PATH_INFO'], siehe Handbuch, für einen ersten Versuch sollte dieses Stückchen erst einmal ausreichen:

              
            <!doctype html>  
            <html><body><pre>Hallo <?php  
                echo htmlspecialchars($_SERVER['PATH_INFO']);  
            ?> !</pre></body></html>  
            
            

            Dann rufst Du mal folgende URLs auf:

            http://dein.web.server/hallo.php
            http://dein.web.server/hallo.php/Welt
            http://dein.web.server/hallo.php/Mehr/Text
            http://dein.web.server/hallo.php/Dop:pel:punk:te
            http://dein.web.server/hallo.php/Frage?Antwort!

            Das letzte Ergebnis wird Dich vielleicht überraschen, wenn ja, lass Dir mal die diversen anderen Schlüssel der $_SERVER-Variable anzeigen (siehe Handbuch).

            Um das ".php" in der URL wirst Du vermutlich nur dann herumkommen, wenn Du mod_rewrite benutzen kannst, um einen internen Redirekt auszuführen, oder vieleicht mit AddHandler/SetHandler.

            Alexander

            --
            Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
            1. Moin Moin!

              Immerhin kenne ich jetzt das Prinzip :) Nur leider Benutze ich einen kostenlosen Webhost, bei dem ich keine eigenen CGI Scripts oder Perl habe (aber PHP). Gibt es da einen "allgemeinen" Weg, wie ich mir meinen Server so konfiguriere, damit ich mein Zeil habe (vielleicht mit einer .htaccess-Datei?)?

              Der Server dürfte bereits (fast) passend konfiguriert sein, mit dem kleinen Haken, dass Du mit ".php/" in der URL leben mußt.

              Ausprobieren kannst Du das ganz leicht. Lege eine PHP-Datei auf ähnlich hohem Niveau wie mein Perl-Script an, z.B. so, dass sie unter http://dein.web.server/hallo.php erreichbar ist. Die Informationen aus PATH_INFO findest Du $_SERVER['PATH_INFO'] bzw. $_SERVER['ORIG_PATH_INFO'], siehe Handbuch, für einen ersten Versuch sollte dieses Stückchen erst einmal ausreichen:

              <!doctype html>
              <html><body><pre>Hallo <?php
                  echo htmlspecialchars($_SERVER['PATH_INFO']);
              ?> !</pre></body></html>

              
              >   
              > Dann rufst Du mal folgende URLs auf:  
              >   
              > http://dein.web.server/hallo.php  
              > http://dein.web.server/hallo.php/Welt  
              > http://dein.web.server/hallo.php/Mehr/Text  
              > http://dein.web.server/hallo.php/Dop:pel:punk:te  
              > http://dein.web.server/hallo.php/Frage?Antwort!  
              >   
              
              Danke, so funktioniert es zumindest! :) Das ist immerhin ein großer Fortschritt...  
              
              > Um das ".php" in der URL wirst Du vermutlich nur dann herumkommen, wenn Du mod\_rewrite benutzen kannst, um einen internen Redirekt auszuführen, oder vieleicht mit [AddHandler](http://httpd.apache.org/docs/2.2/mod/mod_mime.html#addhandler)/[SetHandler](http://httpd.apache.org/docs/2.2/mod/core.html#sethandler).  
              
              Okay, "mod\_rewrite" (habe eigentlich keine Ahnung, was das ist) kann ich glaube ich bei dem Host nicht benutzen, aber die Sache mit SetHandler bzw. AddHandler klingt interessant, was ich evtl. in einer .htaccess-Datei verwenden kann. Könntest du mir vielleicht noch erklären, wie ich das mit PHP-Scripts, falls überhaupt, benutzen kann? Auf Perl und generell eigene CGI-Scripts muss ich bei dem Host leider verzichten.
              
              1. Moin Moin!

                Um das ".php" in der URL wirst Du vermutlich nur dann herumkommen, wenn Du mod_rewrite benutzen kannst, um einen internen Redirekt auszuführen, oder vieleicht mit AddHandler/SetHandler.
                Okay, "mod_rewrite" (habe eigentlich keine Ahnung, was das ist)

                Weißt Du, so langsam geht mir der Humor aus. Begriffe, die Du nicht kennst, kopierst Du bitte ab sofort erst einmal in Googles Eingabeformular und klickst auf den Suchen-Button. Dann folgst Du einigen der Suchergebnis-Links und überfliegst wenigstens mal die ersten paar Absätze. Wahlweise machst du das selbe noch einmal auf der Wikipedia-Homepage.

                kann ich glaube ich bei dem Host nicht benutzen,

                Sagt wer? mod_rewrite ist nicht auf die Hauptkonfigurationsdatei des Webservers beschränkt, und es gibt durchaus Hoster, die ihren Kunden den Einsatz von mod_rewrite erlauben.

                Ein guter Hoster dokumentiert das irgendwo (FAQ, Dokumentation zum Hosting-Paket, Online-Hilfe), andere Hoster geben wenigstens gute Antworten, wenn man den Support fragt, und bei einigen hilft  halt nur stumpfes Ausprobieren. Erstelle eine minimale Konfiguration, lade sie hoch und teste, ob der gewünschte Effekt eintritt. Falls nicht, frag den Hoster, warum es nicht funktioniert.

                aber die Sache mit SetHandler bzw. AddHandler klingt interessant, was ich evtl. in einer .htaccess-Datei verwenden kann. Könntest du mir vielleicht noch erklären, wie ich das mit PHP-Scripts, falls überhaupt, benutzen kann?

                Kennst Du die Abkürzung RTFM? Schlag sie ruhig mal nach, wenn Du schon nicht den Links zur Original-Dokumentation folgen willst.

                Auf Perl und generell eigene CGI-Scripts muss ich bei dem Host leider verzichten.

                Das spielt hier kaum eine Rolle. Wichtig ist eigentlich nur, dass *irgendein* Programm aufgerufen wird, ob das nun in PHP, ASP, JSP, Perl, Shell, LUA oder sonst irgendeiner Sprache gebaut ist. Es klappt sogar mit Server Side Includes, auch wenn man mit denen nicht viel anstellen kann.

                Alexander

                --
                Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
                1. Moin Moin!

                  Um das ".php" in der URL wirst Du vermutlich nur dann herumkommen, wenn Du mod_rewrite benutzen kannst, um einen internen Redirekt auszuführen, oder vieleicht mit AddHandler/SetHandler.
                  Okay, "mod_rewrite" (habe eigentlich keine Ahnung, was das ist)
                  kann ich glaube ich bei dem Host nicht benutzen,

                  Sagt wer? mod_rewrite ist nicht auf die Hauptkonfigurationsdatei des Webservers beschränkt, und es gibt durchaus Hoster, die ihren Kunden den Einsatz von mod_rewrite erlauben.

                  Oke, okee, ich glaub, das geht vielleicht doch, mit Webservern und so habe ich leider nicht besonders viel Ahnung...

                  aber die Sache mit SetHandler bzw. AddHandler klingt interessant, was ich evtl. in einer .htaccess-Datei verwenden kann. Könntest du mir vielleicht noch erklären, wie ich das mit PHP-Scripts, falls überhaupt, benutzen kann?

                  Kennst Du die Abkürzung RTFM? Schlag sie ruhig mal nach, wenn Du schon nicht den Links zur Original-Dokumentation folgen willst.

                  Die Abkürzung ist mir bekannt... Ich habe auf die zwei Links von SetHandler und AddHandler geklickt, mir die Seiten ein wenig durchgelesen, und obwohl ich kaum was verstanden habe, einfach mal was stumpf ohne Erfolg ausprobiert... Ich habe auf der Apache-Seite auch nach mod_rewrite geschaut, wo ich aber auch das meiste nicht kapiert habe...

                  Auf Perl und generell eigene CGI-Scripts muss ich bei dem Host leider verzichten.

                  Das spielt hier kaum eine Rolle. Wichtig ist eigentlich nur, dass *irgendein* Programm aufgerufen wird, ob das nun in PHP, ASP, JSP, Perl, Shell, LUA oder sonst irgendeiner Sprache gebaut ist. Es klappt sogar mit Server Side Includes, auch wenn man mit denen nicht viel anstellen kann.

                  Okay, schön zu wissen.

                  Ich habe jetzt nochmal sorgfältiger nach meine Problem in Google gesucht, und bin auch über folgende Seite gestolpert:
                  http://de.wikipedia.org/wiki/Rewrite-Engine
                  Da steht unter Beispielanwendung ziemlich genau das, was ich gerne hätte. Das habe ich auch gleich erstmal ausprobiert. Auf meiner Seite habe ich stumpf das Verzeichnis "w" erstellt, eine PHP-Datei in dieses Verzeichnis gepackt, den Code für .htaccess (mit RewriteEngine ...) kopiert und in das Wurzelverzeichnis (über w/) gepackt, und ausprobiert:
                  Gebe ich in der Adresse "/w/index.php?title=test", bekomme ich meine Seite und alles ist wunderbar. Gebe ich "/wiki/test" ein, bekomme ich eine (404) Fehlermeldung. Was mache ich falsch?

  2. Moin!

    Ich habe ein kleines Problem. Ich habe auf meiner Seite eine .htacces-Datei angelegt, die beschreibt dass, falls die gesuchte Seite nicht existiert, eine eigene 404-Nachricht ausgibt. Und zwar leitet sie zu der Datei 404.php weiter. Bei dieser Weiterleitung gehen aber alle Post-Daten verloren, die eigentlich an die (nicht gefundene) Seite gehen sollten, welche ich aber in 404.php gerne verarbeiten möchte. Wie mache ich das?

    Meine .htaccess-Datei sieht etwa so aus:
    #-----
    ErrorDocument 404 /404.php
    #-----

    Es gibt keinen Grund, warum POST-Daten da nicht ankommen sollten.

    Andererseits: POST-Daten werden nur von Formularen und Ajax-Requests generiert - es erscheint mir extrem unsinnig, warum man in diesen beiden Situationen die Daten an eine nichtexistente URL senden will.

    Was ist also dein eigentliches Problem?

    - Sven Rautenberg

    1. Andererseits: POST-Daten werden nur von Formularen und Ajax-Requests generiert - es erscheint mir extrem unsinnig, warum man in diesen beiden Situationen die Daten an eine nichtexistente URL senden will.

      Im Falle von Spambots die irgendwelche nicht vorhanden Seiten anposten, wäre es möglicherweise interessant die Werte zu protokollieren.

  3. Hi!

    Warum und wie sendest Du per POST Daten an eine Ressource, die nicht bekannt ist?

    off:PP

    --
    "You know that place between sleep and awake, the place where you can still remember dreaming?" (Tinkerbell)
  4. Hi,

    Meine .htaccess-Datei sieht etwa so aus:
    #-----
    ErrorDocument 404 /404.php
    #-----

    „Etwa“, oder doch signifikant anders?

    Das gezeigte bewirkt keine „Weiterleitung“ im HTTP-Sinne - da sollten alle Eingabedaten wie gewohnt zur Verfügung stehen.

    Wenn du jedoch wirklich eine Weiterleitung vornimmst - dann gibt's natürlich keine POST-Daten mehr, weil der Browser dann das Weiterleitungsziel per GET anfordert.

    Bei 404-Fehler weiterzuleiten, ist das dümmste, was man machen kann. Es unterschlägt in aller Regel den 404-Statuscode, und damit ist der sinnvolle Nutzen komplett dahin.

    MfG ChrisB

    --
    “Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]
    1. Hallo,

      Meine .htaccess-Datei sieht etwa so aus:
      #-----
      ErrorDocument 404 /404.php
      #-----
      „Etwa“, oder doch signifikant anders?

      das spielt in diesem Fall keine so große Rolle, fürchte ich.

      Das gezeigte bewirkt keine „Weiterleitung“ im HTTP-Sinne - da sollten alle Eingabedaten wie gewohnt zur Verfügung stehen.

      Sollten, ja. Hier im Forum wurden aber schon mehrmals Fragen in der Richtung gestellt: Wie kann ich in einem Script, das als ErrorDocument aufgerufen wird, auf die POST-Daten zugreifen? Es sieht so aus, als ob der Apache die POST-Daten schlicht und ergreifend "vergisst", wenn er das ErrorDocument aufruft.

      Bei 404-Fehler weiterzuleiten, ist das dümmste, was man machen kann. Es unterschlägt in aller Regel den 404-Statuscode, und damit ist der sinnvolle Nutzen komplett dahin.

      Full ACK.

      Ciao,
       Martin

      --
      F: Was macht ein Offizier, der in der Nase bohrt?
      A: Er holt das Letzte aus sich heraus.
      1. moin,

        ... Es sieht so aus, als ob der Apache die POST-Daten schlicht und ergreifend "vergisst", wenn er das ErrorDocument aufruft.

        Wieso "vergisst"? Hast Du schonmal das ErrorDocument in STDIN nachschauen lassen? Da stehnse nämlich, die POST-Daten ;-)

        Horst v.d. Post

        --
        Ein Indianer ist nicht nachtragend, aber vergessen tut der auch nichts.
        1. Moin Moin!

          moin,

          ... Es sieht so aus, als ob der Apache die POST-Daten schlicht und ergreifend "vergisst", wenn er das ErrorDocument aufruft.

          Wieso "vergisst"? Hast Du schonmal das ErrorDocument in STDIN nachschauen lassen? Da stehnse nämlich, die POST-Daten ;-)

          Das "große Geheimnis" ist die Environment-Variable REDIRECT_REQUEST_METHOD, die der Apache bei einem INTERNEN Redirect setzt. Die steht bei einem POST auf eine 404-Seite nämlich tatsächlich auf POST. Aber offensichtlich wertet PHP in diesem Fall nur die normale REQUEST_METHOD aus, und die ist tatsächlich GET.

          Bleibt die Frage nach dem Sinn.

          Wenn unter einer gewissen URL ein Programm POST-Daten auswerten soll, dann bitte mit einem "richtigen" Redirect (301, 302, 307) und nicht mit 404. 404 ist kein Redirect, auch wenn Apache einen INTERNEN Redirect macht, um eine eigene 404-Seite zu ermöglichen. Oder statt der Redirects stumpf den kürzestmöglichen URL-Prefix finden und dort ein Programm hinsetzen, dass PATH_INFO auswertet.

          Siehe übrigens auch Doing a proper 404 redirect.

          Alexander

          --
          Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
          1. Moin Moin!

            Hai,

            moin,

            ... Es sieht so aus, als ob der Apache die POST-Daten schlicht und ergreifend "vergisst", wenn er das ErrorDocument aufruft.

            Wieso "vergisst"? Hast Du schonmal das ErrorDocument in STDIN nachschauen lassen? Da stehnse nämlich, die POST-Daten ;-)

            Das "große Geheimnis" ist die Environment-Variable REDIRECT_REQUEST_METHOD, die der Apache bei einem INTERNEN Redirect setzt. Die steht bei einem POST auf eine 404-Seite nämlich tatsächlich auf POST. Aber offensichtlich wertet PHP in diesem Fall nur die normale REQUEST_METHOD aus, und die ist tatsächlich GET.

            Bleibt die Frage nach dem Sinn.

            Wenn unter einer gewissen URL ein Programm POST-Daten auswerten soll, dann bitte mit einem "richtigen" Redirect (301, 302, 307) und nicht mit 404. 404 ist kein Redirect, auch wenn Apache einen INTERNEN Redirect macht, um eine eigene 404-Seite zu ermöglichen. Oder statt der Redirects stumpf den kürzestmöglichen URL-Prefix finden und dort ein Programm hinsetzen, dass PATH_INFO auswertet.

            Siehe übrigens auch Doing a proper 404 redirect.

            Wow, danke für Deine ausführlichen Infos und den Link!!!!

            Viele Grüße,
            Horst Sorglos