Sebastian94

Moin,
bei Sessions ist wichtig, dass du sie ganz zum Anfang der Verarbeitung des Requests startest. Vorher darf noch keine Ausgabe an den Browser gesendet werden. Ansonsten kommt ein "headers already sent" Fehler, die sind bei Anfängern öfter mal zu finden: https://php-de.github.io/jumpto/headers-already-sent/.
Die Anwendung von Sessions sieht so aus: (https://www.php.net/manual/de/session.examples.basic.php)
<?php session_start(); // PHP sagen, dass du mit Sessions arbeiten möchtest // Prüfen ob in der Session der Wert "zaehler" existiert if (!isset($_SESSION['zaehler'])) { // Wert "zaehler" initialisieren, falls es ihn noch nicht gibt $_SESSION['zaehler'] = 0; } else { // "zaehler" um 1 erhöhen, falls es ihn bereits gibt $_SESSION['zaehler']++; }  
So:


 
 

Moin,
nach der Verarbeitung des Formulars kannst du einen redirect auf die URL des nächsten Formulars anstoßen.
<?php // ... header('location:https://example.com/formular2.php'); exit; Das wäre der einfachste Weg, wenn die Formulare unter eigenen URLs erreichbar sind.
 
Wenn alles über eine einzige URL läuft, kannst du das so machen wie du es beschrieben hast. Anhand der Parameter im Request erst erkennen welches Formular gerade verarbeitet wurde und dann entsprechend das nächste Formular includen.
Z.B. gibst du in den einzelnen Formularen eine Kennung per hidden Feld an den Request.
<form method="post" action="https://example.com/formular.php" > <label for="name">Name</label> <input type="text" name="name" id="name"> <input type="hidden" name="formularId" value="1" /> <input type="submit" /> </form> Und am Ende der Verarbeitung in PHP:
<?php // ... $formularId = (int) $_POST['formularId'] ?? 0; if ($formularId === 0) { include '.....formular1.php'; } if ($formularId === 1) { include '.....formular2.php'; } if ($formularId === 2) { include '.....formular3.php'; }

Hier gibt es ein paar Hintergründe dazu:
https://www.ionos.de/digitalguide/server/knowhow/localhost/

Grob gesagt: "localhost" ist tatsächlich immer genau das: der eigene Host, und zwar ausschließlich intern, "für sich".
Der Hostname "localhost" ist immer an das sog. (interne) loopback interface gebunden.
Du kannst viele unterschiedliche Hosts (mit unterschiedlichen IPs) haben, wenn du bei denen jeweils "localhost" eingibst, wissen die automatisch, dass die selbst gemeint sind, noch bevor irgendwas mit IP-Adressen passiert.
Oder anders gesagt: Die Adressierung "localhost" funktioniert auch, wenn überhaupt keine IP-Adressen verteilt / eingestellt wurden (s.o.: weil dann eben nicht die "normalen" Netzwerk Interfaces verwendet werden, sondern das loopback).
#####
Wenn du hingegen mit IP-Adressen arbeitest, dann wird der Weg über das Netzwerk genommen - allein die "Überlegung" des Hosts, er könnte ja auch selbst damit gemeint sein, steht nicht an erster Stelle, bzw. sie findet überhaupt nicht statt.
Da wird stumpf das Netzwerk-Protokoll abgearbeitet, und es ist NICHT einmal so, dass (wenn er aus dem Netzwerk die entspr. Info erhalten hat), er evtl. merkt "Huch, das bin ich ja selber". Selbst dann wird trotzdem der traffic ganz normal über das entspr. Netzwerk-Interface rausgehen, an irgendeinem Switch / Router landen (der weiß, wohin der traffic zu fließen hat), und dann gehts wieder zurück an den Host.
#####
Zu der IP range bei localhost:
Da bin ich nicht 100% sicher, aber das dürfte daran liegen, dass zu Zeiten der Einführung IP(v4)-Adressen noch wie Sand am Meer verfügbar waren

Der Switch wird auch nur jede IP ein mal in der ARP-Tabelle speichern / cashen. Deshalb wird das Szenario "Switch sendet das selbe Packet an zwei Rechner mit der gleichen IP" gar nicht eintreffen können. Dagegen ist eine MAC-Adresse mit mehreren IPs durchaus möglich.
Nehmen wir unter dieser Voraussetzung doch mal das Szenario an: zwei Rechner haben die selbe IP, aber nur einer ist in der ARP-Tabelle des Switches drin. Dann wird dieser alle Antworten bekommen, auch die von dem anderen Rechner mit der selben IP gesendeten Anfragen und auf höheren Layern die Pakete dann ignorieren/verwerfen.
Das erinnert mich an eine LAN-Party damals, an der zwei aus versehen die selbe IP verwendet haben. Bei dem einen hat alles funktioniert, bei dem anderen gar nichts  Aber hier sind wir zum Glück noch lange nicht an einem Netzwerk-Crash.

das knallt schon vorher, beim Switch bzw beim ARP Protokoll.
Um eine IP Adresse anzusprechen muss ein Gerät rauskriegen welche MAC dazu gehört. Dazu dient das ARP Protokoll und hier gilt das Highlander Prinzip. Weiterhin vermittelt ein Switch ein Paket auf Basis von IP und MAC Adresse ...
Wenn eine IP doppelt vergeben ist wüsste der Switch nicht wohin damit. Daher schaltet jedes vernünftige OS sein Interface ab wenn es mitbekommt dass die IP schon vergeben ist
Kollisionen oder Netzausfall ? Hab ich noch nie gesehen. Beide Hosts schalten ihren IP Stack innerhalb von Sekunden ab damit genau das nicht passiert

Dass er sich entscheiden muss, entweder Netzklassen oder Classless Inter-Domain Routing.
Die Frage nach der Netzklasse bei CIDR ist ungefähr so als würde man fragen aus welchem Tier das vegane Schnitzel gemacht wurde.

Jein wirklich falsch ist es nicht, aber genau darum geht es ja, sozusagen die Abschaffung bzw. Loslösung von den Klassen: Die Einteilung in Klassen ist, grob gesagt, einfach schon ziemlich alt.
Moderner (und tatsächlich auch sinnvoller, mMn., weil wesentlich flexibler) ist eben die CIDR-Notation (= ClassLESS Inter-Domain Routing) -> es wurden bewusst die Klassen abgeschafft.

So wie ich das gelernt habe ist diese Einteilung in A,B,C,D und E-Netz willkürlich. Historisch gewachsen. Ich lernte es auswendig und gut.
 
Das andere sind Adressbereiche, die privaten IP-Adressen vorbehalten sind. So wie die privaten Adressen, die dein Gerät von deiner Fritz!Box anfordert.
 
Ich hoffe, dass ich helfen konnte

Hier muss unterschieden werden zwischen zwei Dingen:
1) private IP address ranges
2) Definitionen von Netzwerk-Klassen
zu 1)  - private IP Adressen
Die offizielle Version sagt hier klar:
10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) -> also 8/12/16 - festgelegt im RFC 1918
siehe zB hier:
https://datatracker.ietf.org/doc/html/rfc1918#section-3
#####
Dann 2) - Netzwerk-Klassen
Die wurden - mehr oder weniger willkürlich - aufgeteilt in A bis E.
Das sind dann die sog. "classful networks":
https://en.wikipedia.org/wiki/Classful_network#Classful_addressing_definition
Hier gilt dann:
Class A   /8
Class B   /16
Class C   /24
Diese Bezeichnungen der Netzwerk-Klassen überlappen sich (sozusagen zufällig) mit den privaten IP-Adressen bei /8, aber das sind halt zwei verschiedene Dinge.
Und ja, die Einteilung in bzw. Bezeichnung als "Netzwerk-Klassen" ist antiquiert, CIDR ist halt der moderne Stand der Dinge.
Trotzdem mag es vorkommen, dass man mal drüber stolpert. Für die Prüfung ist es relevant, und es grundsätzlich zu wissen kann zumindest auch nicht schaden