Forum: PC-Programmierung HTTP GET und POST


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Mutti (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von TR.OLL (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Nutz JS und Ajax.

von Mutti (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von STK500-Besitzer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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).

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Mutti (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Mutti (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von STK500-Besitzer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mutti schrieb:
> Eigentlich soll POST nur übermitteln.

Da geht es um REST-APIs, nicht um HTTP allgemein.

von Mutti (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Mutti (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Da gibts wohl das Location-Field im HTTP-Header, habe ich gerade 
gelesen. Das wird wohl genutzt, um Clients weiterzuleiten.

von Mutti (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich trolle nicht. Ah...klar es ist ein Unterschied, ob man etwas anfragt 
oder umleitet. Eine Umleitung setzt keine Anfrage voraus.

von Mutti (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke trotzdem für die Hilfe. Du hast mich auf die richtige Spur 
gebracht und denk nicht so schlecht über deine Mitmenschen.

von FS (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Mutti (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Weingut P. (weinbauer)


Bewertung
0 lesenswert
nicht lesenswert
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'>

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gret (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Mutti (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@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?

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Weingut P. (weinbauer)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Vegane Rohpolnische (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mutti schrieb:
> e

Mutti schrieb:

> Wer kann mir dieses Rätsel lösen?
man Affenformular

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.