Hallo dedlfix, hallo Alle, > > da mich die Frage mit dem HEAD-Request auf PHP-Ressourcen durchaus tiefer interessiert, habe ich noch ein wenig tiefer recherchiert, und bin auf [diesen Thread](https://www.phpgangsta.de/das-problem-mit-head-requests-in-php) in [phpgansta.de](https://phpgangsta.de) gestoßen. > > Da ist man als Programmierer selbst schuld. HEAD-Requests sind wie GET. Wer bei GET serverseitige Daten verändert, hat sowieso ein Problem. Das macht ein HEAD-Request dann auch nicht mehr schlimmer. > > Zudem kann jedes Script auch durch andere Ursachen abgebrochen werden. Wer (bei POST) kritische Dinge macht, und diese nicht in einer Transaktion absichert, hat nicht unbedingt Mitleid verdient. Bitte nimm es nicht übel, aber mich stört immer diese "Hülsensprache". Könntest Du deine Aussagen etwas konkretisieren, ggf. mit Beispielen? Bei HEAD vs. GET kann ich noch mithalten. Mit beiden sollten keine datenverändernden Abfragen durchgeführt werden. Spannend bleibt da die Grenzziehung bei den Sessiondaten, wie das zugegeben konstruierte Beispiel von phpgangsta zeigt. Wie man bereits in der PHP-Schicht kaputte Daten verhindern kann, das wird hier noch nicht klar. Es gibt dafür die Funktionen rund um [ignore_user_abort()](https://www.php.net/manual/de/function.ignore-user-abort.php), die man ab einem gewissen Fortschritt in der Logik eines Controllers immer benutzen sollte - auf jeden Fall vor dem Auslösen eines DMS (Data Modification Statement) an der Datenhaltung. Eine Transaktion ist imho nur für den Kern des DMS selber verantwortlich, nicht aber für seine vollständige Ausführung. Wird bei Skriptabbruch mitten in einer komplexen Transaktion das Rollback trotzdem durchgeführt, oder fällt das unter den Tisch? Imho entstehen viele Inkonsistenzen an Web-Datenbeständen gerade an dieser Stelle. Es bleibt also die Frage offen, wie sauber die Transaktion gekapselt ist und damit unabhängig vom vorzeitigen Abbruch des Skriptes ist. Und wie gestaltet man eine vollständig gekapselte Transaktion, wenn gar kein gesonderter Datenbankserver im Spiel ist (SQLite, o.ä.)? LG + Gesundheit Localhorst

Hallo dedlfix, hallo Alle, > > da mich die Frage mit dem HEAD-Request auf PHP-Ressourcen durchaus tiefer interessiert, habe ich noch ein wenig tiefer recherchiert, und bin auf [diesen Thread](https://www.phpgangsta.de/das-problem-mit-head-requests-in-php) in [phpgansta.de](https://phpgangsta.de) gestoßen. > > Da ist man als Programmierer selbst schuld. HEAD-Requests sind wie GET. Wer bei GET serverseitige Daten verändert, hat sowieso ein Problem. Das macht ein HEAD-Request dann auch nicht mehr schlimmer. > > Zudem kann jedes Script auch durch andere Ursachen abgebrochen werden. Wer (bei POST) kritische Dinge macht, und diese nicht in einer Transaktion absichert, hat nicht unbedingt Mitleid verdient. Bitte nimm es nicht übel, aber mich stört immer diese "Hülsensprache". Könntest Du deine Aussagen etwas konkretisieren, ggf. mit Beispielen? Bei HEAD vs. GET kann ich noch mithalten. Mit beiden sollten keine datenverändernden Abfragen durchgeführt werden. Spannend bleibt da die Grenzziehung bei den Sessiondaten, wie das zugegeben konstruierte Beispiel von phpgangsta zeigt. Wie man bereits in der PHP-Schicht kaputte Daten verhindern kann, das wird hier noch nicht klar. Es gibt dafür die Funktionen rund um [ignore_user_abort()](https://www.php.net/manual/de/function.ignore-user-abort.php), die man ab einem gewissen Fortschritt in der Logik eines Controllers immer benutzen sollte - auf jeden Fall vor dem Auslösen eines DMS (Data Modification Statement) an der Datenhaltung. Eine Transaktion ist imho nur für den Kern des DMS selber verantwortlich, nicht aber für seine vollständige Ausführung. Wird bei Skriptabbruch mitten in einer komplexen Transaktion das Rollback trotzdem durchgeführt, oder fällt das unter den Tisch? Imho entstehen viele Inkonsistenzen an Web-Datenbeständen gerade an dieser Stelle. Es bleibt also die Frage offen, wie sauber die Transaktion gekapselt ist und damit unabhängig vom vorzeitigen Abbruch des Skriptes ist. LG + Gesundheit Localhorst

Hallo dedlfix, hallo Alle, > > da mich die Frage mit dem HEAD-Request auf PHP-Ressourcen durchaus tiefer interessiert, habe ich noch ein wenig tiefer recherchiert, und bin auf [diesen Thread](https://www.phpgangsta.de/das-problem-mit-head-requests-in-php) in [phpgansta.de](https://phpgangsta.de) gestoßen. > > Da ist man als Programmierer selbst schuld. HEAD-Requests sind wie GET. Wer bei GET serverseitige Daten verändert, hat sowieso ein Problem. Das macht ein HEAD-Request dann auch nicht mehr schlimmer. > > Zudem kann jedes Script auch durch andere Ursachen abgebrochen werden. Wer (bei POST) kritische Dinge macht, und diese nicht in einer Transaktion absichert, hat nicht unbedingt Mitleid verdient. Bitte nimm es nicht übel, aber mich stört immer diese "Hülsensprache". Könntest Du deine Aussagen etwas konkretisieren, ggf. mit Beispielen? Bei HEAD vs. GET kann ich noch mithalten. Mit beiden sollten keine datenverändernden Abfragen durchgeführt werden. Spannend bleibt da die Grenzziehung bei den Sessiondaten, wie das zugegeben konstruierte Beispiel von phpgangsta zeigt. Wie man bereits in der PHP-Schicht kaputte Daten verhindern kann, das wird hier noch nicht klar. Es gibt dafür die Funktionen rund um [ignore_user_abort()](https://www.php.net/manual/de/function.ignore-user-abort.php), die man ab einem gewissen Fortschritt in der Logik eines Controllers immer benutzen sollte - auf jeden Fall vor dem Auslösen eines DMS (Data Modification Statement) an der Datenhaltung. Eine Transaktion ist imho nur für den Kern des DMS selber verantwortlich, nicht aber für seine vollständige Ausführung. Wird bei Skriptabbruch mitten im einer komplexen Transaktion das Rollback trotzdem durchgeführt, oder fällt das unter den Tisch? Imho entstehen viele Inkonsistenzen an Web-Datenbeständen gerade an dieser Stelle. Es bleibt also die Frage offen, wie sauber die Transaktion gekapselt ist und damit unabhängig vom vorzeitigen Abbruch des Skriptes ist. LG + Gesundheit Localhorst