Diskussion:Post/Redirect/Get

Inhaltliche Fehler (erl.)

Sorry, aber der Artikel ist haarsträubend.

"Wenn der Anwender ungeduldig ist und das Formular mittels eines GET neu lädt, so kann das Formular mittels eines POST erneut gesendet werden und dadurch einen unerwünschten Zustand verursachen."

Schwachsinn. Wenn der Anwender das Formular mittels GET neu lädt, passiert genau das: Es wird per GET geladen und nicht auf magische Weise per POST.

"Um das Problem des doppelten POST zu verhindern, wird der Benutzer beim Einleiten des Bestellvorgangs mittels des HTTP-Statuscode „303: See Other“ auf eine Seite umgeleitet, welche mittels der GET-Methode auf die erfolgreiche Bearbeitung des POST-Vorgangs wartet. Lädt der Benutzer vor der Beendigung der Bearbeitung die Seite erneut, kommt er wieder auf die Warteseite und kann keinen erneuten POST absetzen."

Schwachsinn. Der Redirect wird erst NACH Bearbeitung des POST-Requests an den Client gesendet. Da wird nicht auf magische Weise ein zweiter Request erzeugt, der auf die Beendigung des ersten wartet. Natürlich kann man die Anfrage asynchron im Hintergrund verarbeiten und vorab mit einer Statusseite antworten, die auf das finale Ergebnis wartet, das hat aber genau gar nichts mit dem PRG-Pattern an sich zu tun. Die aktuell beschriebene "Funktionsweise" steht übrigens im Widerspruch zum dargestellten Diagramm, welches das PRG-Pattern korrekt wiedergibt. Das PRG-Pattern verhindert keine Doppelposts während einer lang andauernden POST-Anfrage, es verhindert ausschließlich Doppelposts NACH Abschluss der POST-Anfrage.

"In einer Single-Page-Webanwendung kann der „Submit“-Button deaktiviert werden, um ein erneutes Absetzen der POST-Methode zu verhindern."

Was hat das mit Single-Page zu tun? In JEDER Webanwendung kann der Submit-Button deaktiviert werden. Der besondere Zusammenhang zwischen Single-Page-Anwendungen und dem PRG-Pattern erschließt sich mir nicht.

Vielleicht wäre es sinnvoller, einfach nur den Artikel aus der englischsprachigen Wikipedia zu übernehmen und durch einen Übersetzer zu wursten. Wäre schön wenn sich jemand erbarmt, den Artikel zu korrigieren. Ich mache das nicht, weil erfahrungsgemäß eh wieder alle Änderungen rückgängig gemacht werden. Ohne inhaltliche Warnung an unbedarfte Leser kann der Artikel aber IMHO nicht stehenbleiben. --62.144.227.11 09:37, 17. Feb. 2023 (CET)

Die hier bemängelten Passagen sind in dem Artikel nicht mehr zu finden, also hat ihn wohl jemand seither bearbeitet.

Ich habe ihn heute in kleinem Umfang für Grammatik-Korrekturen und Lesbarkeit überarbeitet und fand ihn auch für mich als Laien einigermaßen nachvollziehbar. Da ich aber die IT-spezifischen Aussagen nicht beurteilen kann, lasse ich den Überarbeiten-Hinweis auf der Artikel-Seite stehen. --DeeDelDum (Diskussion) 12:41, 17. Aug. 2024 (CEST)

Ist wohl OK in der aktuellen Fassung; der Überarbeitungsbaustein wurde heute entfernt. --DeeDelDum (Diskussion) 17:45, 3. Nov. 2024 (CET)