GET und POST

IT 12.6 – Webanwendungen · Einheit 10 · Café-App Schritt 10

Lernziele

Du kannst beschreiben, wie Formulardaten mit GET und mit POST übertragen werden.
Du kannst eine Adresse mit Parametern angeben, auch mit Leerzeichen und Sonderzeichen.
Du kannst die Auswirkungen von GET und POST auf den Browser erläutern (Adressleiste, Verlauf, Lesezeichen, Neuladen).
Du kannst eine HTTP-Anfrage lesen und ihre Teile benennen.
Du kannst begründen, wann GET und wann POST die passende Methode ist.

Rückblick

1. Was bekommt der Browser zurück, wenn er ein PHP-Skript aufruft?

Nur das HTML, das das Skript erzeugt hat. Der PHP-Code bleibt auf dem Server (Einheit 9).

2. Wie kommt ein Skript an den Wert des Eingabefelds <input name=“klasse”>?

Über $_GET['klasse'] oder $_POST['klasse'], je nachdem, wie das Formular gesendet wurde. Der Schlüssel ist das name-Attribut (Einheit 9).

3. Warum prüft bestellung.php die Anzahl, obwohl das Formular schon max=“5” hat?

Weil man die Anfrage verändern kann. Nur die Prüfung auf dem Server ist verbindlich (Einheit 9).

Ein Link, der funktioniert, und einer, der es nicht tut

Ben sucht auf der Speisekarte des Cafés nach „Muffin“ und schickt seiner Freundin die Adresse aus der Adressleiste. Sie öffnet den Link und sieht sofort dieselben Suchergebnisse.

Lea hat gerade bestellt und sieht die Seite „Danke, Lea!“ mit ihrer Abholnummer. Sie schickt die Adresse dieser Seite ebenfalls weiter. Ihr Freund öffnet den Link, sieht aber nur eine Fehlermeldung. Und als Lea die Danke-Seite neu lädt, fragt der Browser plötzlich, ob er „die Daten erneut senden“ soll.

Überlege: Was steckt in Bens Adresse, das in Leas Adresse fehlt? Und warum fragt der Browser nur bei Lea nach?

Erkunden: Zwei Wege zum Server

Bevor du weiterliest: Bearbeite die Erkundungen. Die Erklärungen weiter unten helfen dir erst danach.

Erkundung 1: Dieselbe Bestellung, zwei Methoden mittel

Unter der Browser-Ansicht kannst du einstellen, mit welcher Methode das Bestellformular sendet.

Simulation eines Webservers für cafe.example: Alles läuft in deinem Browser, nichts wird übertragen oder gespeichert. Klicke Links an und schicke Formulare ab.

Das hat der Browser an den Server geschickt:

Anfrage von Hand ändern und senden

So wie mit den Entwicklerwerkzeugen kann man eine Anfrage beliebig verändern. Der Server muss damit rechnen.

Was der Server bei der letzten Anfrage getan hat:

Das hat der Server zurückgeschickt (Kopfzeilen und HTML):

Formular in bestellen.html sendet mit

a) Schicke eine Bestellung mit POST ab (so ist es eingestellt). Gib an, wo deine Daten in der Anfrage stehen (Reiter Anfrage). Sieh dir außerdem die Adressleiste und den Reiter Verlauf an.

b) Stelle auf GET um, gehe mit ← zurück zum Formular und schicke dieselbe Bestellung noch einmal ab. Vergleiche die Anfrage, die Adressleiste und den Verlauf mit a).

c) Der Server antwortet bei GET mit einer Fehlermeldung. Erkläre mithilfe des Reiters Server, woran das liegt.

d) Nenne für beide Methoden, wer die Bestelldaten sehen kann, der später an deinem Rechner sitzt.

Tipp 1

Zu c): Lies den ersten Schritt im Ablauf und vergleiche ihn mit der ersten Zeile von bestellung.php. Aus welcher Liste liest das Skript?

Lösung

Erkundung 2: Neu laden und Sonderzeichen mittel

Simulation eines Webservers für cafe.example: Alles läuft in deinem Browser, nichts wird übertragen oder gespeichert. Klicke Links an und schicke Formulare ab.

Das hat der Browser an den Server geschickt:

Anfrage von Hand ändern und senden

So wie mit den Entwicklerwerkzeugen kann man eine Anfrage beliebig verändern. Der Server muss damit rechnen.

Was der Server bei der letzten Anfrage getan hat:

Das hat der Server zurückgeschickt (Kopfzeilen und HTML):

a) Gehe auf „Bestellen“ und schicke eine Bestellung ab. Drücke dann ⟳ (Neu laden). Beschreibe, was der Browser fragt. Vermute, was passiert, wenn du „Erneut senden“ wählst, und prüfe es im Reiter Datenbank.

b) Gehe auf die Speisekarte und suche nach Muffin. Drücke dann ⟳. Vergleiche mit a).

c) Suche nach Apfel & Tee und danach nach Käse. Beschreibe, wie der Browser das Leerzeichen, das & und das ä in der Anfrage schreibt. Begründe, warum das & nicht einfach so in der Adresse stehen darf.

Tipp 1

Zu c): Sieh dir an, wozu das & in der Adresse sonst schon benutzt wird, zum Beispiel bei einer Bestellung mit GET aus Erkundung 1.

Lösung

Zwei Methoden

Vergleicht eure Ergebnisse. Ein Formular legt mit dem Attribut method fest, wie der Browser die Daten an das Skript in action schickt:

<form action="speisekarte.php" method="get">   <!-- Daten an die Adresse hängen -->
<form action="bestellung.php" method="post">   <!-- Daten in den Inhalt der Anfrage -->

Ohne method verwendet der Browser GET. In beiden Fällen schickt er alle Felder mit name als Paare name=wert, getrennt durch &.

GET: Daten in der Adresse

Bei GET hängt der Browser die Daten nach einem ? an die Adresse. Dieser Teil heißt Query-String (Abfrageteil), die einzelnen Paare heißen Parameter:

http://cafe.example/speisekarte.php?begriff=tee&sortierung=preis

Teil	Beispiel
Protokoll	`http://`
Host (Webserver)	`cafe.example`
Pfad (Skript)	`/speisekarte.php`
Query-String	`begriff=tee&sortierung=preis`, eingeleitet mit `?`
Parameter	`begriff` = `tee` und `sortierung` = `preis`, getrennt durch `&`

Eine GET-Anfrage hat keinen Inhalt. Weil die Daten zur Adresse gehören, kann man sie auch in einen Link schreiben: <a href="speisekarte.php?begriff=tee">Tee</a> ruft das Skript genauso auf wie das Suchformular.

POST: Daten im Inhalt der Anfrage

Bei POST stehen die Daten im Inhalt (englisch body) der Anfrage. Eine HTTP-Anfrage ist reiner Text und besteht aus vier Teilen:

POST /bestellung.php HTTP/1.1
Host: cafe.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 48

name=Lisa&klasse=11FO&produkt=1&anzahl=1&pause=1

Startzeile: Methode, Pfad (bei GET mit Query-String), Version von HTTP
Kopfzeilen (Header): zusätzliche Angaben, z. B. Host (welcher Webserver), Content-Type (in welcher Form der Inhalt geschrieben ist) und Content-Length (wie viele Bytes der Inhalt hat)
eine Leerzeile
der Inhalt, bei GET leer

Sonderzeichen in Adressen

Einige Zeichen haben in Adressen eine feste Aufgabe (?, &, =, #, /). Leerzeichen, Umlaute und diese Zeichen in Werten muss der Browser deshalb umschreiben. Das heißt URL-Kodierung (Prozent-Kodierung):

Zeichen	kodiert	Warum?
Leerzeichen	`+` (in Formulardaten) oder `%20`	Leerzeichen sind in Adressen nicht erlaubt
`&`	`%26`	trennt sonst die Parameter
`=`	`%3D`	trennt sonst Name und Wert
`ä`	`%C3%A4`	Umlaute werden als Bytes in UTF-8 geschrieben, jedes Byte als `%` und zwei Hexadezimalziffern

Bei POST wird der Inhalt genauso kodiert (application/x-www-form-urlencoded). PHP macht die Kodierung automatisch rückgängig: In $_GET und $_POST stehen wieder die ursprünglichen Werte.

Was GET und POST für den Browser bedeuten

	GET	POST
Daten stehen …	in der Adresse (Query-String)	im Inhalt der Anfrage
Adressleiste, Verlauf, Lesezeichen	enthalten die Daten	enthalten nur die Adresse des Skripts
Weitergeben als Link	möglich	nicht möglich
Neu laden	ohne Rückfrage	Browser fragt, ob er die Daten erneut senden soll
Menge der Daten	begrenzt, weil Adressen nicht beliebig lang sein dürfen (die Grenze hängt von Browser und Server ab)	auch große Datenmengen und Dateien

Hinzu kommt: Webserver schreiben die aufgerufenen Adressen meist in ihre Protokolldateien (Logs). Daten in einer GET-Adresse landen also auch dort.

Der Standard für HTTP legt fest, dass GET-Anfragen auf dem Server nichts verändern sollen. Browser, Suchmaschinen und Vorschauen in Messengern rufen GET-Adressen nämlich manchmal von selbst auf, zum Beispiel um eine Vorschau anzuzeigen.

Café-App: Schritt 10

Café-App, Schritt 10: Bestellung senden und Links mit Einstellungen mittel

Teil A: Die Bestellung wirklich senden

Ändere in app.js die Funktion, die auf submit reagiert: event.preventDefault() soll nur noch aufgerufen werden, wenn es Fehler gibt. Ist alles in Ordnung, schickt der Browser das Formular an bestellung.php.
Die Bestätigung „Danke, …“ kommt jetzt vom Server. Lösche die Zeilen, die sie im Browser erzeugen, sowie den Absatz <p id="bestaetigung"> in bestellen.html und die Zeile in app.js, die ihn leert.
Teste mit Live Server: Öffne vor dem Absenden die Entwicklerwerkzeuge (F12) und dort den Reiter Netzwerk. Schicke eine gültige Bestellung ab. Beschreibe, welche Anfrage du dort siehst und wo die Daten stehen. Live Server zeigt danach eine Fehlermeldung, weil er kein PHP ausführen kann. Das ist hier erwartet.
Schicke ein ungültiges Formular ab und prüfe, dass keine Anfrage an bestellung.php geht.

Teil B: Links mit Einstellungen

Die Speisekarte soll sich über die Adresse einstellen lassen, zum Beispiel zeigt speisekarte.html?vegan=ja&sortierung=auf nur vegane Produkte, die günstigsten zuerst.

Lies beim Start in app.js die Parameter aus der Adresse und setze damit das Häkchen „nur vegan“ und die Sortierung, bevor die Speisekarte angezeigt wird. Dafür gibt es new URLSearchParams(location.search). Mit .get('vegan') bekommst du den Wert des Parameters vegan oder null, wenn er fehlt.
Ergänze auf der Startseite im Abschnitt „Unser Angebot“ einen Link „Alle veganen Produkte, günstigste zuerst“, der diese Ansicht öffnet.

Tipp 1

Zu 1: Verschiebe die Zeile event.preventDefault(); vom Anfang der Funktion in den Block if (fehler.length > 0) { … }.

Tipp 2

Zu 5: Setze die Werte im Abschnitt „Verbinden und starten“, also vor speisekarteLaden();. Wenn die Daten geladen sind, ruft speisekarteLaden die Funktion aktualisieren auf, und die liest das Häkchen und die Sortierung aus.

Tipp 3

Zu 6: Im HTML schreibt man das & in einem href am saubersten als &.

Stand nach Schritt 10

Aufgaben

Aufgabe 1: Adressen lesen und bilden leicht

a) Die Mediathek der Schule zeigt Suchergebnisse unter dieser Adresse:

http://mediathek.example/suche.php?titel=Emil&nur_frei=ja&seite=2

Gib den Host, den Pfad und alle Parameter mit ihren Werten an. Gib außerdem an, welchen Wert $_GET['seite'] im Skript hat.

b) Ein Formular für eine Fahrplanauskunft:

<form action="fahrplan.php" method="get">
  <input name="von">  <input name="nach">  <input name="zeit">
  <button>Suchen</button>
</form>

Jemand gibt bei „von“ Gießen Bahnhof, bei „nach“ Wetzlar und bei „zeit“ 7:30 ein. Gib die Adresse an, die der Browser aufruft. Der Doppelpunkt wird dabei als %3A, das ß als %C3%9F geschrieben.

Lösung

Aufgabe 2: GET oder POST? leicht

Ordne jedem Formular die passende Methode zu und begründe kurz.

Suche im Online-Fahrplan
Anmeldung mit Benutzername und Passwort
Profilbild hochladen
Seite 3 der Suchergebnisse anzeigen
Filter „nur Bücher, die gerade frei sind“
Kommentar unter einem Artikel absenden
Wettervorhersage für eine Stadt abrufen
Lieferadresse im Kundenkonto ändern

Lösung

Aufgabe 3: Den Unterschied erläutern mittel

Die Schülervertretung plant ein Formular, mit dem man sich für den Sponsorenlauf anmeldet (Name, Klasse, Anzahl der Runden, die man schaffen will). Im Team wird diskutiert, ob das Formular mit GET oder mit POST senden soll.

Erläutere einen wesentlichen Unterschied zwischen GET und POST in Bezug auf die Übertragung der Daten und die Auswirkungen auf den Browser. Beziehe dich dabei auf das Anmeldeformular und gib eine Empfehlung.

Tipp 1

Ein guter Aufbau: erst die Übertragung (wo stehen die Daten?), dann zwei Folgen für den Browser (was sieht man wo, was passiert beim Neuladen?), dann die Empfehlung mit Begründung.

Lösung (Beispiel)

Aufgabe 4: Eine Anfrage analysieren mittel

Diese Anfrage wurde mit den Entwicklerwerkzeugen aufgezeichnet:

POST /wunsch.php HTTP/1.1
Host: abiball.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 48

name=Jana+Marie&wunsch=Kakao+%26+Brezel&anzahl=2

a) Benenne die Teile der Anfrage.

b) Gib an, welche Werte im Skript wunsch.php in $_POST['name'], $_POST['wunsch'] und $_POST['anzahl'] stehen.

c) Rekonstruiere das HTML des Formulars, das diese Anfrage erzeugt haben könnte (form-Element mit action und method, die Felder mit name).

d) Erkläre, warum Content-Length den Wert 48 hat.

Lösung

Aufgabe 5: Ist POST sicher? schwer

Ein Mitschüler sagt: „Unsere Anmeldeseite schickt das Passwort mit POST. Man sieht es nicht in der Adresse, also ist es sicher. HTTPS brauchen wir dafür nicht.“

Nimm Stellung zu dieser Aussage.

Tipp 1

Sieh dir in Erkundung 1 noch einmal den Reiter Anfrage an. In welcher Form steht der Inhalt da? Wer kann eine Anfrage auf dem Weg zum Server mitlesen?

Tipp 2

Aus IT 12.4 kennst du TLS: Was schützt es, und was nicht?

Lösung (Beispiel)

Aufgabe 6: Löschen per Link schwer

Im Team-Bereich des Cafés soll man falsche Bestellungen löschen können. Ein Teammitglied schlägt vor, in jede Tabellenzeile einen Link zu setzen:

<a href="loeschen.php?nummer=B003">löschen</a>

a) Beurteile den Vorschlag. Nenne mindestens drei Situationen, in denen eine Bestellung ungewollt gelöscht werden könnte.

b) Entwickle eine bessere Lösung als HTML für eine Tabellenzeile.

Tipp 1

Zu a): Denke an den Verlauf, an das Teilen von Links und an Programme, die Adressen von selbst aufrufen.

Lösung (Beispiel)

Zusatzaufgabe: Nie wieder doppelt bestellen schwer Zusatz

Ergänzend. Viele Webanwendungen verhindern doppelte Bestellungen beim Neuladen mit dem Muster Post/Redirect/Get (PRG): Nach einer erfolgreichen POST-Anfrage schickt der Server keine Seite, sondern eine Weiterleitung, zum Beispiel:

HTTP/1.1 303 See Other
Location: danke.php?nummer=B004

Der Browser ruft die Adresse aus Location daraufhin von selbst mit GET auf.

a) Stelle den Ablauf vom Klick auf „Bestellung abschicken“ bis zur angezeigten Danke-Seite als Folge von Anfragen und Antworten dar.

b) Erläutere, was jetzt beim Neuladen der Danke-Seite passiert.

c) Beurteile, ob man die Danke-Seite gefahrlos als Link weitergeben kann.

Lösung (Beispiel)

Zusammenfassung

method="get": Die Daten hängen als Query-String an der Adresse (?name=wert&name2=wert2). Ohne Angabe gilt GET.
method="post": Die Daten stehen im Inhalt der Anfrage, nach den Kopfzeilen und einer Leerzeile.
Eine HTTP-Anfrage besteht aus Startzeile, Kopfzeilen, Leerzeile und Inhalt.
URL-Kodierung: Leerzeichen → + oder %20, & → %26, ä → %C3%A4. PHP dekodiert automatisch.
GET: in Adressleiste, Verlauf, Lesezeichen und Server-Logs sichtbar, als Link teilbar, Neuladen ohne Rückfrage, begrenzte Länge.
POST: nicht in der Adresse, Neuladen nur nach Rückfrage, auch für große Daten und Dateien. POST verschlüsselt nichts.
GET zum Abrufen, POST zum Senden und Verändern. Formular und Skript müssen dieselbe Methode verwenden.

Selbstcheck

Geh die Fragen ehrlich durch. Wenn du bei einer unsicher bist, lies den verlinkten Abschnitt noch einmal oder bearbeite die passende Aufgabe.

Kannst du beschreiben, wie Daten mit GET und mit POST übertragen werden? → Erkundung 1, GET: Daten in der Adresse, POST: Daten im Inhalt der Anfrage
Kannst du eine Adresse mit Parametern angeben, auch mit Sonderzeichen? → Erkundung 2, Sonderzeichen in Adressen, Aufgabe 1
Kannst du die Auswirkungen auf den Browser erläutern? → Was GET und POST für den Browser bedeuten, Aufgabe 3
Kannst du eine HTTP-Anfrage lesen? → POST: Daten im Inhalt der Anfrage, Aufgabe 4
Kannst du begründen, wann GET und wann POST passt? → Aufgabe 2, Aufgabe 5, Aufgabe 6, Café-App

Wortspeicher

Begriff	Bedeutung in einfachen Worten
GET	Methode, bei der die Daten an die Adresse gehängt werden; zum Abrufen
POST	Methode, bei der die Daten im Inhalt der Anfrage stehen; zum Senden und Verändern
Query-String	Teil der Adresse nach dem `?` mit den Parametern
Parameter	ein Paar `name=wert` in der Adresse oder im Inhalt
URL-Kodierung	Umschreiben von Sonderzeichen in Adressen, z. B. `&` als `%26`
Startzeile	erste Zeile einer HTTP-Anfrage mit Methode, Pfad und Version
Kopfzeilen (Header)	Zusatzangaben der Anfrage, z. B. `Host` oder `Content-Length`
Inhalt (Body)	Daten nach der Leerzeile, bei POST die Formulardaten
Verlauf	Liste der besuchten Adressen im Browser
Protokolldatei (Log)	Datei, in der der Server die Anfragen mitschreibt
`URLSearchParams`	liest in JavaScript die Parameter aus einer Adresse

Quellen

Hessisches Kultusministerium: Kerncurriculum Fachoberschule, Fachrichtung Technik, Schwerpunkt Informationstechnik, Themenfeld 12.6 Webanwendungen, „Unterschiede POST/GET“, „Formulare: Übertragung und Validierung von Formularinhalten“ (Stand November 2022).
HTTP-Methoden und „sichere“ Methoden nach RFC 9110 (HTTP Semantics, 2022), Prozent-Kodierung nach RFC 3986. Freie Dokumentation: MDN Web Docs, HTTP-Anfragemethoden (Du verlässt jetzt Maternet).
Texte, Beispiele, Aufgaben und der Server-Simulator sind selbst erstellt. cafe.example, mediathek.example, abiball.example und bahn.example sind Beispieladressen nach RFC 2606.