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?
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.
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.
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.
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.
