Ich weiß nicht, ob das das richtige Forum für meine Frage ist, aber ein Versuch ist es wert. Es geht um die HTTP-Anfragemethoden GET, POST usw. Angenommen ein Kunde schickt mit mit einem HTML-Formular und der POST-Methode eine Pizzabestellung zu einer PHP-Datei namens verarbeitung.php, die auf dem Webserver des Pizza-Bäckers liegt. DDort werden die Daten in der besagten PHP-Datei mit der $_POST-Variable abgefangen und zur Übersicht nochmal ausgegeben. Dank der Ausgabe werden dem Kunden ja gleich nach dem Abschicken noch einmal alle Bestelldetails angezeigt. Nun habe ich einen inneren Konflikt. Wie bekommt der Kunde die Ausgabe aus der verarbeitung.php überhaupt angezeigt? Er hat ja schließlich nur die POST-Methode verwendet und die erstellt in erster Linie eine neue Ressource. Er hat die Datei verarbeitung.php nicht explizit mit GET angefragt. Wer kann mir dieses Rätsel lösen?
Achso sorry, ich habe verseen es zu erwähnen. Mir geht es nur darum, das Prinzip von POST zu verstehen. Dahinter steckt kein wirkliches Projekt.
GET und POST sind nur Methoden, wie man per HTML Formular-Daten "<form method="GET">" oder "<form method="POST">"überträgt. Wenn man Daten per GET überträgt, sieht man sie in der Adresszeile, bei POST eerden sie nicht so angezeigt und können auch größer sein (Bilder oder andere Daten auf den Webserver hochladen).
Mutti schrieb: > Wie bekommt der Kunde die Ausgabe aus der verarbeitung.php überhaupt > angezeigt? In dem sein Browser die Seite wechselt, auf eine Seite in der die Ergebnisse des Post eingearbeitet sind. Es sei denn, er SOLL gar nichts mitbekommen.
MaWin schrieb: > In dem sein Browser die Seite wechselt, auf eine Seite in der die > Ergebnisse des Post eingearbeitet sind. Aber laut Definition, fordert POST keine neue Ressource an. Das wäre dann ja ein POST in Kombination mit einem GET. Erst übermitteln, dann anzeigen.
Mutti schrieb: > Wie bekommt der Kunde die Ausgabe aus der verarbeitung.php überhaupt > angezeigt? Er hat ja schließlich nur die POST-Methode verwendet und die > erstellt in erster Linie eine neue Ressource. Genau da ist der Denkfehler, POST ist keine Einbahnstrasse. Der Client bekommt auch dann genau wie beim GET eine Antwort geschickt.
Hmmm schrieb: > Genau da ist der Denkfehler, POST ist keine Einbahnstrasse. Der Client > bekommt auch dann genau wie beim GET eine Antwort geschickt. Ich habe hier https://restfulapi.net/http-methods/#post und hier https://www.predic8.de/post-put-patch-beispiel.htm gelesen, dass das dem Design-Prinzip von POST widerspricht. Eigentlich soll POST nur übermitteln.
Mutti schrieb: > Aber laut Definition, fordert POST keine neue Ressource an. Das wäre > dann ja ein POST in Kombination mit einem GET. Erst übermitteln, dann > anzeigen. Jetzt hat mein (selbstprogrammiertes) Lagerdatensystem ein Problem.
Mutti schrieb: > Eigentlich soll POST nur übermitteln. Da geht es um REST-APIs, nicht um HTTP allgemein.
Hmmm schrieb: > Da geht es um REST-APIs, nicht um HTTP allgemein. Das sollte keinen Unterschied machen. Schau die mal die Definition der HTTP-POST-Methode auf Wikipedia an, da wird auch nicht erwähnt, dass zu einer anderen Seite umgeleite wird.
Mutti schrieb: > da wird auch nicht erwähnt, dass zu einer anderen Seite umgeleite wird. Von einer Umleitung war nie die Rede. Aber wer als "Mutti" schreibt und solche Fragen stellt, will wohl ohnehin nur trollen.
Da gibts wohl das Location-Field im HTTP-Header, habe ich gerade gelesen. Das wird wohl genutzt, um Clients weiterzuleiten.
Ich trolle nicht. Ah...klar es ist ein Unterschied, ob man etwas anfragt oder umleitet. Eine Umleitung setzt keine Anfrage voraus.
Danke trotzdem für die Hilfe. Du hast mich auf die richtige Spur gebracht und denk nicht so schlecht über deine Mitmenschen.
Der Unterschied zwischen GET und POST ist sehr schön im RFC2616 zu HTTP/1.1 unter Abschnitt 9 erläutert. POST soll zwar nur übermitteln, d.h. aber nicht, dass nach erfolgreicher Übermittlung nicht beispielsweise auf eine andere Seite weitergeleitet wird, die dann das Ergebnis anzeigt oder bei einem Fehler eine Fehlermeldung. Jedes Webforum wird auf diese Weise funktionieren. Übrigens auch dieses Formular hier. POST ist übrigens heute datenschutztechnisch in vielen Fällen zu bevorzugen, in denen auch GET ausreichen würde. Eben weil die Parameter nicht mehr in der URL stehen.
FS schrieb: > POST soll zwar nur übermitteln, d.h. aber nicht, dass nach erfolgreicher > Übermittlung nicht beispielsweise auf eine andere Seite weitergeleitet > wird Das ist ja richtig. Ich stelle die Frage ja nicht ohne Grund. Ich habe eine beispielhafte Pizza-Bestellung mit PHP programmiert, eine Bestellung (POST) abgeschickt und mit mit Firefox die HTTP-Header der Response und Requests ausgewertet. Es ist darin kein Feld (z. B. Location) enthalten, das auf die Ressource verweist, an die ich die Daten gesendet habe, dennoch wird zu der Ressource weitergeleitet. Wie und warum?
Mutti schrieb: > FS schrieb: >> POST soll zwar nur übermitteln, d.h. aber nicht, dass nach erfolgreicher >> Übermittlung nicht beispielsweise auf eine andere Seite weitergeleitet >> wird > > Das ist ja richtig. Ich stelle die Frage ja nicht ohne Grund. Ich habe > eine beispielhafte Pizza-Bestellung mit PHP programmiert, eine > Bestellung (POST) abgeschickt und mit mit Firefox die HTTP-Header der > Response und Requests ausgewertet. Es ist darin kein Feld (z. B. > Location) enthalten, das auf die Ressource verweist, an die ich die > Daten gesendet habe, dennoch wird zu der Ressource weitergeleitet. > > Wie und warum? wegen dem <form action='xy.php' method='post'>
Mutti schrieb: > Es ist darin kein Feld (z. B. > Location) enthalten, das auf die Ressource verweist, an die ich die > Daten gesendet habe, dennoch wird zu der Ressource weitergeleitet. Was faselst Du da dauernd von "Ressourcen", an die "weitergeleitet" wird? Guck Dir doch einfach mal in der Developer Console den Datentransfer an. In einem <form> steht entweder ein "action"-Parameter, oder es wird implizit die URL genommen, von der das Form stammt. Der Browser schickt dann (bei method="POST") einen POST-Request und zeigt - sofern vorhanden - den zurückgelieferten Content an. Falls kein Content, sondern ein Location-Header zurückkommt, wird der Content von da genommen.
in einem php Ablauf wird in einem Durchlauf eine (!) Seite aufgebaut. Deswegen : 1) auswerten der Uebergabe parameter isset($GET()), resp isset($POST()) 2) noetige Aktionen, zB Datenbank zugriffe 3) Aufbauen und Anzeigen der neuen Seite echo() Die dem Clienten/Browser gelieferte Webseite hat den Aufbau <html> header .. <body> <form action=neue seite method=post>...</form> </body> </html> Der unterschied zwischen GET und POST ist, dass der GET Parameter in der Kommunikation sichtbar ist, der POST parameter nicht. Sichtbar bedeutet hier allenfalls verschluesselt. Auf GET Parameter kann man Links setzen, auf POST nicht. Bedeutet man kann eine Website voll unter ./index.php laufen lassen, verunmoeglicht dann allerdings Links auf Funktionalitaet und zwingt den Benutzer sich jedes mal durch alles durchzuclicken. Das sollte man nicht, kommt schlecht an. Speziell wenn die Navigation unuebersichtlich ist.
@Gret D.h., es existiert kein separates Header-Feld im HTTP-Header, in dem eine URL steht, die angezeigt wird, nachdem man den POST-Request ausgelöst hat. Will sagen, der reine HTTP-Header eines POST-Request enthält keine Weiterleitung?
Mutti schrieb: > Will sagen, der reine HTTP-Header eines POST-Request enthält keine > Weiterleitung Die Weiterleitung steht doch nicht im Request woher soll der den wissen wohin es weiter geht, sondern in der Response Antwort. Entweder ein einfaches 200 (ok) oder 201 (Weiterleitung zu URL soundso) oder Fehler.
Mutti schrieb: > D.h., es existiert kein separates Header-Feld im HTTP-Header, in dem > eine URL steht, die angezeigt wird, nachdem man den POST-Request > ausgelöst hat. Liest Du eigentlich auch mal, was man Dir schreibt? Ich schrieb Dir schon vor Stunden: Hmmm schrieb: > Genau da ist der Denkfehler, POST ist keine Einbahnstrasse. Der Client > bekommt auch dann genau wie beim GET eine Antwort geschickt. Die Antwort auf einen HTTP-POST-Request unterscheidet sich nicht von einer Antwort auf einen HTTP-GET-Request, in beiden Fällen KANN (nicht muss) ein Location-Header dafür sorgen, dass der Content von woanders geholt wird, ansonsten zeigt der Browser das an, was vom Server zurückkommt. Einen POST-Request mit einem Redirect zu beantworten, hat ein paar Vorteile, insbesondere funktioniert dann wieder der Back-Button des Browsers, ohne dass der Browser den POST-Request wegen des ausbleibenden Cachings nochmal schicken will.
Gret schrieb: > Der unterschied zwischen GET und POST ist, dass der GET Parameter in der > Kommunikation sichtbar ist, der POST parameter nicht. Sichtbar bedeutet > hier allenfalls verschluesselt. > Auf GET Parameter kann man Links setzen, auf POST nicht. Bedeutet man > kann eine Website voll unter ./index.php laufen lassen, verunmoeglicht > dann allerdings Links auf Funktionalitaet und zwingt den Benutzer sich > jedes mal durch alles durchzuclicken. Das sollte man nicht, kommt > schlecht an. Speziell wenn die Navigation unuebersichtlich ist. Wobei Landingpages mit Parametern was SEO angeht eher schlecht sind, da biegt man per htaccess die HTML auf die index.php um und zerlegt die "sprechende" URL. läuft technisch aufs Gleiche raus (Auslieferung eines bestimmten Inhalts), schaut aber besser aus bei der Verlinkung.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.