mitmario.dev

Formulardaten verschicken

HTML Im Browser 3 Min Lesezeit 3 BeispieleLektion 2 von 8

Ein Formular kann fertig aussehen und trotzdem nichts ausrichten. Ob es etwas bringt, hängt an drei Angaben, die man auf der Seite nicht sieht, wohin die Daten gehen, auf welchem Weg und unter welchem Namen jeder Wert ankommt.

action und method

Ziel und Weg
<form action="/kontakt-empfangen" method="post">
  <label for="vorname">Dein Vorname</label>
  <input type="text" id="vorname" name="vorname">

  <label for="nachricht">Deine Nachricht</label>
  <input type="text" id="nachricht" name="nachricht">

  <button type="submit">Absenden</button>
</form>

action ist die Adresse, an die der Browser die Daten schickt. Ein Pfad wie hier, nach denselben Regeln wie bei Links. Fehlt action, schickt der Browser an die aktuelle Seite zurück.

method ist der Weg, und davon gibt es zwei.

GET hängt die Werte an die Adresse an, hinter ein Fragezeichen. Aus einer Suche nach „Linsen“ wird /suche?q=Linsen. Das ist sichtbar, kopierbar, als Lesezeichen speicherbar und landet im Browserverlauf. Richtig ist das für Suche, Filter und Sortierung, also überall dort, wo ein Ergebnis teilbar sein soll.

POST schickt die Werte im Rumpf der Anfrage mit, unsichtbar in der Adresszeile. Nichts landet im Verlauf, nichts lässt sich versehentlich weitergeben. Richtig ist POST für alles, was etwas verändert oder privat ist, eine Anmeldung, eine Bestellung, eine Nachricht oder ein neues Passwort.

Ich entscheide an einer Frage. Ändert das Abschicken etwas auf dem Server, nehme ich POST, fragt es nur etwas ab, GET.

Verschlüsselt ist POST übrigens nicht, es steht nur nicht in der Adresszeile. Verschlüsselung kommt von HTTPS, und die brauchst du in beiden Fällen.

name ist der Schlüssel

Ohne name kommt nichts an
<form action="/kontakt-empfangen" method="post">
  <label for="vorname">Dein Vorname</label>
  <input type="text" id="vorname">

  <button type="submit">Absenden</button>
</form>

Hier fehlt am input das name-Attribut. Optisch ändert das nichts, das Formular sieht vollständig aus, der Knopf reagiert, und trotzdem kommt beim Server nichts an, nicht einmal ein leerer Wert.

Der Browser packt die Daten als Paare aus Name und Wert. Ohne Namen gibt es kein Paar, und das Feld wird beim Absenden übersprungen.

Der Fehler ist besonders zäh, weil auf der Seite nichts darauf hindeutet. Kein Fehler im Browser, keine rote Meldung, nur ein Formular, das scheinbar geht und leer ankommt. Eine Stelle sagt es trotzdem, und die kommt am Ende dieser Lektion.

name und id sind zwei verschiedene Dinge. Die id ist für die Seite, sie verbindet das label mit dem Feld und dient JavaScript und CSS als Anker. Der name ist für den Server, er ist der Schlüssel, unter dem der Wert ankommt. Dass beide oft gleich heißen, wie im Beispiel vorname, ist Bequemlichkeit und keine Regel.

Bei Textfeldern ist der Wert das, was der Nutzer tippt. Bei Checkboxen, Radios und Auswahllisten legst du ihn selbst über value fest, das kommt in den nächsten Lektionen.

GET in der Praxis

Eine Suche mit GET
<form action="/suche" method="get">
  <label for="q">Rezept suchen</label>
  <input type="search" id="q" name="q">

  <button type="submit">Suchen</button>
</form>

Ein Suchformular ist der Musterfall für GET. Der name ist hier kurz q, und deshalb sehen Such-URLs im ganzen Web ähnlich aus: ?q= und dahinter der Suchbegriff.

Daran sieht man gut, dass die Namen der Felder Teil der öffentlichen Adresse werden. Sie sollten also kurz und sprechend sein, und sie sind nichts Geheimes.

Nach einer Suche steht in der Adresszeile /suche?q= und dahinter der Suchbegriff. So ist es auch auf einer echten Seite, nur antwortet dort ein Server. Hier kommt stattdessen die Meldung, dass es die Seite /suche nicht gibt, und das stimmt, denn gebaut ist nur die Adresse und keine Seite dahinter.

Beim ersten Beispiel steht nach dem Absenden nur /kontakt-empfangen in der Adresszeile, kein Fragezeichen, kein Name, keine Nachricht. Die Werte sind trotzdem unterwegs, im Rumpf der Anfrage.

Ansehen lässt sich der im Reiter „Netzwerk“. Dort steht die Anfrage als POST, ein Klick klappt sie auf, und unter „Anfrage-Rumpf“ stehen die Werte in derselben Schreibweise, die bei GET in der Adresse steht. Dieselben Daten also, nur in einem anderen Umschlag.

Beim mittleren Beispiel, dem ohne name, steht die Anfrage im Reiter „Netzwerk“ ebenfalls, aber sie lässt sich nicht aufklappen, weil es nichts aufzuklappen gibt. Ein leerer Wert kommt also nicht an, sondern gar keiner.

In der Aufgabe stehen zwei Formulare, eine Suche und ein Rezeptwunsch, und jedes bekommt sein Ziel, seinen Weg und Namen für seine Felder.

Zum Mitnehmen

action nennt das Ziel, method den Weg, GET in der Adresse für alles, was nur abfragt, POST im Rumpf der Anfrage für alles, was etwas ändert. Jedes Feld braucht einen name, sonst überspringt der Browser es beim Absenden, ohne etwas zu melden.

Jetzt du

Basis Konto, kostenlos

Zu dieser Lektion gehört eine Aufgabe. Du schreibst den Code selbst, und nach jedem Lauf sagt dir eine Prüfliste, was schon stimmt.

Dafür brauchst du das Basis Konto. Es kostet nichts, und ein Passwort gibt es auch nicht.

Was in dieser Lektion steckt

  • Artikel mit 3 Beispielen zum Ausprobieren

    Steht hier, ohne Konto lesbar.

  • Aufgabe im Editor, direkt im Browser geprüft

    Öffnet sich mit dem Basis Konto.