Dokument erloschen Problem

[tsunami]

Hallo Zusammen, ich habe in einer Webanwendung das altbekannte Problem mit dem "Dokument erloschen."

Mit der Suche bin ich hier gelandet und habe mit ini_set('session.cache_limiter', 'private'); Scheinbar eine Lösung gefunden.

Aber nun gibt es keinen Refresh der Seiten mehr. Bedeutet, ich habe og Code an den Anfang vor die Session gepackt. Dann habe ich Formular, schicke es mit Submit ab. Die neuen Daten erscheinen aber erst nach einem Reload der Seite. Das soll natürlich nicht sein. Wie bekomme ich das Ganze rund? mfG tsunami

[Der Martin]

Hallo,

ich habe in einer Webanwendung das altbekannte Problem mit dem "Dokument erloschen."

altbekannt? Ich kenne das Problem nicht. Auch die Meldung nicht.

Mit der Suche bin ich hier gelandet und habe mit ini_set('session.cache_limiter', 'private'); Scheinbar eine Lösung gefunden.

Wobei du hier anscheinend einen Unterstrich zum Punkt gemacht hast.

Dann habe ich Formular, schicke es mit Submit ab. Die neuen Daten erscheinen aber erst nach einem Reload der Seite.

Hier ist ein Informationsvakuum. Was macht das Formular? Mit welcher Methode wird es abgeschickt? Die Ergebnisseite eines Formulars, das mit POST abgeschickt wurde, lässt sich normalerweise nicht einfach mit einem Refresh neu laden, weil dazu die Formulardaten erneut gesendet werden müssten und die Aktion auf dem Server (Datenbank-Eintrag, Mail-Versand o.ä.) eventuell ein weiteres Mal ausgelöst wird.

Und nur als Schlussbemerkung: Mit HTML hat das gar nichts zu tun.

Einen schönen Tag noch
 Martin

[Rolf B]

Hallo Martin,

nein nein, die INI Angabe hat den Punkt und die PHP Funktion, die die Ini-Angabe überschreiben kann, hat den Unterstrich. Das ist schon richtig.

Mir ist das Problem allerdings ebenfalls unbekannt. Das kann daran liegen, dass ich dauerverchromt bin und Füchse aus Tierschutzgründen vom Feuer fernhalte.

Aber in Chrome ist das Problem als "ERR_CACHE_MISS" bekannt.

Grundsätzlich ist das ja eine gute Sache - man WILL nicht, dass der User ein Formular ausfüllt, es POSTet, dann "ZURÜCK" drückt und das Formular nochmal gepostet wird. Das ist der Hintergrund, warum es diese Meldung gibt.

Mit ini_set("session.cache_limiter", "private") bzw. session_cache_limiter("private") - beides das Gleiche - verhindert man das Neuposten, aber eben auch um den Preis, dass man die Daten sieht, die vor dem Post gültig waren. Weil man den Cache-Inhalt des Browsers sieht. Und das möchte man bei einer Formularanwendung eigentlich auch nicht.

Deswegen programmieren viele das PRG Pattern (Post-Redirect-Get), d.h. wenn man im PHP einen POST verarbeitet, gibt man die Ergebnisseite nicht direkt aus, sondern erzeugt einen Redirect, so dass die neuen Daten per GET abgeholt werden.

Ablauf ohne PRG - am Beispiel eines Wizard-Dialogs mit mehreren Seiten

• User lädt theWizard.php

• GET von theWizard.php -> Erste Formularseite anzeigen

• User füllt Seite 1 aus

• POST von theWizard.php mit Daten von Seite 1 -> Daten für Seite 1 senden, zweite Formularseite anzeigen

• User füllt Seite 2 aus

• POST von theWizard.php mit Daten von Seite 2 -> Daten für Seite 2 senden, dritte Formularseite anzeigen

Problemmöglichkeit 1: User merkt, dass er einen Fehler gemacht hat, und klickt "Zurück".

• POST von theWizard.php mit Daten von Seite 1

Problemmöglichkeit 2: Die Seite lädt langsam, der User wird ungeduldig und drückt F5

• POST von theWizard.php mit Daten von Seite 2

Beides ist unerwünscht und kann - je nach Programmlogik - zu Mehrfachbuchungen oder Datenkorruption führen. Deswegen sagt Dir der Browser: TU DAS NICHT UNBEDACHT

Verwendet man das PRG Pattern, wird nach jedem Post ein GET gemacht. Drückt man dann F5, wird der GET wiederholt. Zumindest in Chrome ist es so, dass der ZURÜCK-Button nicht auf Seiten mit Status 302 springt, sondern nur auf die 200er Seiten

Tatsächlich bin ich nicht wirklich sicher, ob cache_limiter=private eine gute oder schlechte Sache ist. Daten von vor einem POST im Browser zu cachen ist etwas, das man sich gut überlegen sollte.

Rolf

[Raketenwilli]

Deswegen programmieren viele das PRG Pattern (Post-Redirect-Get), d.h. wenn man im PHP einen POST verarbeitet, gibt man die Ergebnisseite nicht direkt aus, sondern erzeugt einen Redirect, so dass die neuen Daten per GET abgeholt werden.

Ich erlaube mir die Frechheit, die von Rolf B vorgestellte, auch nach meinem Wissen stets funktionierende und gut erklärte Lösung des eigentlichen Problems mal hervorzuheben.

Fragen:

1. Funktioniert das Bewertungssystem denn wirklich nicht?
2. Können nur nicht angemeldete Nutzer den „Betreff“ bzw. das „Topic” ändern?

Tipp: Beide Fragen sind „irgendwie anders“ gemeint.

[Rolf B]

Hallo Raketenwilli,

danke für's Vatertagsblümchen 😉

Eine Antwort als "akzeptiert" zu markieren ist - meine ich - dem Threadersteller vorbehalten. Ich kann's auch (nicht für eigene Beiträge), ich weiß aber nicht ob das an meinen Moderatorenrechten liegt.

Insofern: Wenn Du deinen alten Account reaktivieren würdest oder dich unter einem neuen Namen reregistriertest, könntest Du dieses Feature vermutlich ebenfalls nutzen. Mit 50 Punkten, die DU sicher schnell hast (sofern Du Dich nicht mit Leuten rumzankst und Minusse sammelst 😉), könntest Du zumindest ein + vergeben.

Dass Forengäste das Bewertungsfeature nicht unbedingt beachten - es also auf Layer 8 definitiv nicht so funktioniert wie beabsichtigt, darüber denke ich gar nicht mehr nach. Dass Du diesen Weg wählst, um dagegen zu sticheln, und das auch noch mit einem expliziten Hinweis unterstreichst, könnte mir fast schon ein - wert sein, wenn das denn nicht ebenfalls gegen den Sinn des Bewertungssystems wäre.

Rolf

[Raketenwilli]

danke für's Vatertagsblümchen

Bin heute morgen mit Bussen (via Prag) und Sonnenbrand(!) von einer Hütten-, Wander-, Sauf- und „Heldentatenbegehungs“-Tour im Iser + Riesengebirge zurückgekommen.

Dass Du diesen Weg wählst, um dagegen zu sticheln,

Na! Diesmal nicht. Ich wollte mehr daran erinnern, das System auch zu nutzen. Ich bin ja sicher nicht der Einzige, der erkannt hat, das die Antwort richtig ist.

Eine Antwort als "akzeptiert" zu markieren ist - meine ich - dem Threadersteller vorbehalten.

„Sollso”. Ist auch richtig. Aber irgenwie muss ebenjemen auch dabei helfen, die besseren Antworten zu erkennen.

[Gunnar Bittersmann]

@@Raketenwilli

Bin heute morgen mit Bussen (via Prag) und Sonnenbrand(!) von einer Hütten-, Wander-, Sauf- und „Heldentatenbegehungs“-Tour im Iser + Riesengebirge zurückgekommen.

Dafür hast du auch ein − verdient, weil du mich nicht mitgenommen hast!!1

Liegt noch Schnee ganz oben? Oder in den Śnieżne Kotły (Schneegruben)?

🖖 Живіть довго і процвітайте

[Raketenwilli]

Auf der Schneekoppe selbst war ich dieses Mal wegen schlechten Wetters nicht, bei 1500 Metern sind wir gen Süden abgebogen. Und habe selbige wegen der dichte Wolken auch nicht gesehen. Ich (und die anderen) wollten dann keine Karte wie diese schreiben:

Schlappe Beine.
Aussicht? Keine!

Heinrich Heine

Es lag oberhalb von 1200 Metern über NN noch Einiges. Beim Abstieg habe ich dann Reste von Schneewehen mit aktuell (25.05.2022) etwas mehr 5 Meter Höhe gesehen - und das war nicht in der von Dir gezeigten Schlucht…

Dafür hast du auch ein − verdient, weil du mich nicht mitgenommen hast!

Darüber kann man reden.

[tsunami]

Hallo zusammen, vielen Dank für die superschnellen Antworten. Ok, dann etwas mehr Infos. Die Methode ist Post. Ich finde es immer schöner, wenn der User gar nicht sieht was passiert und auch nicht auf dumme Gedanken kommt.

Es ist kein spezielles Formular sondern generell. Unter allen Seiten habe ich oder möchte ich zwei Komforlinks anbieten:

<h5 class="ueberschriftdoko">
   <a href="javascript:history.back();" class="textlink">zur&uuml;ck</a> - <a href="#oben" class="textlink">hoch</a>
</h5>
<br>
</div>
<br/><br/><br/>

Einfach, wenn der Usersich verklickt hat oder doch nichts ändern möchte oder sonstwas. Er kann natürlich auch die Browser-Buttons nehmen. Nur das soll er gar nicht, da später das Ziel eine Webanwendung ist, welche im Vollbild läuft.

Dann kommt natürlich Dokument erloschen. Entweder muss ich bei meiner Lösung bleiben und ein Reload hinterherschicken oder das Ganze ändern.

Es sind genau genommen 2 Probleme. Einmal habe ich das Problem mit dem Dokuemnt erloschen mit dem og Codeschnipsel erledigt. Aber dann funktionen alle Formulare nicht mehr richtig. ZB Neuen Termin erfassen -> Formular abgeschickt, in speichern.php verarbeiten, in die DB schreiben usw. Danach Weiterleitung zu Termine.php. Dort steht der neue Termin aber erst nach einen Reload. Hoffe, das es nun klarer ist? mfG tsunami

[Der Martin]

Hallo,

Ok, dann etwas mehr Infos. Die Methode ist Post. Ich finde es immer schöner, wenn der User gar nicht sieht was passiert und auch nicht auf dumme Gedanken kommt.

das sollte nicht die Begründung sein. POST sollte immer dann verwendet werden, wenn ein Request eine Aktion auslöst, die Daten verändert (wie etwa ein Eintrag in einer Datenbank), während GET verwendet werden sollte, wenn man den Request mehrmals absenden könnte, ohne dass sich dadurch am Ergebnis etwas ändert.

Daher ist POST in deinem Fall genau die richtige Wahl.

Es ist kein spezielles Formular sondern generell. Unter allen Seiten habe ich oder möchte ich zwei Komforlinks anbieten:

<h5  class="ueberschriftdoko"><a href="javascript:history.back();" class="textlink">zur&uuml;ck</a> - <a href="#oben" class="textlink">hoch</a></h5><br></div><br/><br/><br/>`

Dazu ein paar Anmerkungen.
Ich glaube nicht, dass du fünf Gliederungsebenen in deinem Dokument hast. Ein h5-Element ist daher mit an Sicherheit grenzender Wahrscheinlichkeit hier falsch.
Ich halte es auch nicht für sinnvoll, die Back-Navigation des Browsers nochmal mit einem Link nachbilden zu wollen - aber das ist nur meine Meinung.
Das Verstümmeln von Umlauten ist ein Relikt aus dem vergangenen Jahrtausend, als man noch davon ausging, dass möglicherweise irgendwo auf dem Übertragungsweg nur ASCII unterstützt würde. Das ist heute Unfug, der Standard-Zeichensatz ist Unicode. Und damit kann man sämtliche Umlaute und auch Zeichen anderer Sprachen im Klartext schreiben.
Und schließlich ist das br-Element kein Rudeltier, mit dem Abstände erzeugt werden sollen. Dazu ist CSS da.

Dann kommt natürlich Dokument erloschen.

Ah, jetzt verstehe ich. Das liegt daran, dass die Antwort eines POST-Requests normalerweise nicht im Cache gespeichert wird, denn sie wurde ja vom Server dynamisch "zusammengebaut".

Entweder muss ich bei meiner Lösung bleiben und ein Reload hinterherschicken oder das Ganze ändern.

Ein Reload ändert nichts daran. Die POST-Adresse bleibt ja trotzdem in der Browser History. Die saubere Lösung ist, aus der POST-Ressource heraus gar keine Antwortseite zu generieren, sondern nur einen Redirect auf die sinngemäß entsprechende Seite, die dann mit GET abgerufen wird. Die POST-Ressource (bzw. deren Adresse) landet dann nicht in der Browser History.

Es sind genau genommen 2 Probleme. Einmal habe ich das Problem mit dem Dokuemnt erloschen mit dem og Codeschnipsel erledigt. Aber dann funktionen alle Formulare nicht mehr richtig. ZB Neuen Termin erfassen -> Formular abgeschickt, in speichern.php verarbeiten, in die DB schreiben usw. Danach Weiterleitung zu Termine.php.

Dann machst du in der Verarbeitung noch etwas grundlegend falsch, was aus der Beschreibung so nicht erkennbar ist.

Dort steht der neue Termin aber erst nach einen Reload.

Das ist so nicht in Ordnung.

Einen schönen Tag noch
 Martin

[tsunami]

Hallo zusammen, ich glaube ichich habe das Kernproblem(e) erstmal gelöst: <h5 class="ueberschriftdoko"><a href="'.$_SERVER['HTTP_REFERER'].'" class="textlink">zur&uuml;ck</a>

Das <br> nicht optimal ist, weiß ich. Da aber die Seiten unterschiedlich sind und ich den part in einer externen bottom.php untergebracht habe, die bei allen Seiten eingebunden wird, wird es mit margin-top:... etwas schwierig, da ich dann x verschiedene Styles nehemn müsste. Also was weiß ich class="zuruecktermine", class="zurueckdashboard", class="zurueckdetails" usw.

Und <h5 find ich einfach optisch schöner, als irgendwas mit <span oder <div. <h4 ist zu groß. Ok, das mit dem utf8 schaue ich mir nochmal an. Hatte aber in der Vergangenheit Probleme, dass obwohl utf 8 die Daten verkrüppelt in der Datenbank landeten. Oder aber bei tcpdf. Und so funktionierte es problemlos. Gruß tsunami

[Auge]

Hallo

Das <br> nicht optimal ist, weiß ich. Da aber die Seiten unterschiedlich sind und ich den part in einer externen bottom.php untergebracht habe, die bei allen Seiten eingebunden wird, wird es mit margin-top:... etwas schwierig, da ich dann x verschiedene Styles nehemn müsste. Also was weiß ich class="zuruecktermine", class="zurueckdashboard", class="zurueckdetails" usw.

Um das mal möglichst wenig kryptisch zu kommentieren: ???

Und <h5 find ich einfach optisch schöner, als irgendwas mit <span oder <div. <h4 ist zu groß.

Diese Elemente haben in den Browsern zwar vorgegebene, aber je Browser unterschiedlich sein könnende Gestaltungen. Das ist aber nicht ihr Selbstzweck. HTML-Elemente haben eine Bedeutung in der Dokumentstruktur. Dass sie aussehen, wie es dir passt, ist quasi Zufall und kann sich im Übrigen in dem einen oder anderen Browser zu irgendeiner Zeit/Version auch ändern.

Und dann?

Dann ist die hier mehrfach beschriebene Forderung nach der Trennung von Struktur und Gestaltung relevant. Undzwar von Anfang an (nicht erst, wenn ein Browserhersteller etwas ändert). Wenn du willst, dass ein Text, der keine Überschrift ist, so aussieht, wie der Browser eine Überschrift ausgibt (fett, kursiv, Fontgröße, was auch immer), dann gib das per CSS so an aber behaupte im HTML nicht, es wäre eine Überschrift. Denn das ist sie nicht.

Hatte […] in der Vergangenheit Probleme, dass obwohl utf 8 die Daten verkrüppelt in der Datenbank landeten. Oder aber bei tcpdf.

In solchen Fällen ist davon auszugehen, dass in der Verarbeitungskette (speichern, bearbeiten, ausgeben) irgendein Schritt nicht mit UTF-8 umgehen konnte/kann.

Tschö, Auge

[Rolf B]

Hallo tsunami,

deine Argumentation mit margin-top verstehe ich nicht, das klingt so, als hättest Du da grundlegen Sanierungsbedarf im Konzept. Ohne deine Seite zu kennen, kann man da aber kaum sinnvoll raten.

Und <h5 find ich einfach optisch schöner,

Wie Auge schon sagte: <h5> ist eine Überschrift und hat entsprechende Bedeutung. Wenn Dir die Darstellung eines div nicht gefällt, ändere sie - über CSS. Wenn Du ein h5 setzt, wo es nicht hingehört, finden das andere nicht nur optisch, sondern ggf. auch aural oder taktil unschön.

Rolf

[Auge]

Hallo

Hallo tsunami,

deine Argumentation mit margin-top verstehe ich nicht, das klingt so, als hättest Du da grundlegen Sanierungsbedarf im Konzept. Ohne deine Seite zu kennen, kann man da aber kaum sinnvoll raten.

Ich vermute, dass der Footer von sich aus nicht am unteren Viewportrand sondern direkt unterhalb des Seiteninhalts sitzt, was tsunami mit einer pro Seite unterschiedlichen Anzahl von brs zu beheben sucht. Das sieht, bei zu wenig Seiteninhalt, halt määh aus. Wie das mit einer Flexbox oder einem Grid zu beheben ist, hast du schon mehrfach ausführlich und (mMn) sehr gut beschrieben.

Falls @tsunami meine Vermutung bestätigen sollte, brauchst du nur noch die Karten auf den Ti… ähh … die Links zu deinen Erklärbärpostings hier zu hinterlegen. 🙂

Tschö, Auge

[MudGuard]

Hi,

Ich vermute, dass der Footer von sich aus nicht am unteren Viewportrand sondern direkt unterhalb des Seiteninhalts sitzt, was tsunami mit einer pro Seite unterschiedlichen Anzahl von brs zu beheben sucht.

was aber schon deshalb nicht funktionieren kann, weil die Fenstergröße bei jedem Besucher eine andere ist bzw. sein kann und damit die Anzahl der brs nicht bekannt ist ...

cu,
Andreas a/k/a MudGuard

[Rolf B]

Hallo MudGuard,

weswegen ich schreibte:

Ohne deine Seite zu kennen, kann man da aber kaum sinnvoll raten.

Rolf

[tsunami]

Wird schwierig, da es erstmal nur im xampp läuft. Es ist keine Seite im eigendlichen Sinn, sondern eine Webanwendung.

Zum Thema Zeichen: <!DOCTYPE html> <html lang="de"> <head> <meta charset="utf-8"/> steht normal über der Seite. In der Db steht Claudia Müller. Testausgabe: Claudia M?ller. Db ist auf utf8 german2 formatiert. Gut kein html. Deswegen die entities.

OK Fehler gefunden. DAtenbank war OK, Seite war ok, nur die DB Verbindung war falsch. Nun scheint es zu gehen.

[Rolf B]

Hallo tsunami,

ja, die Zeichenkodierung End-To-End korrekt einzurichten kann mühsam sein...

Rolf

[Der Martin]

Hallo,

<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="utf-8"/>

steht normal über der Seite.

und stimmt das auch? Auf einem Gurkenglas kann auch ein Etikett kleben, auf dem "Rollmops" steht. Davon allein werden die Gurken aber noch nicht zu Rollmöpsen.

In der Db steht Claudia Müller. Testausgabe: Claudia M?ller.

So sieht das aus, wenn man UTF-8 erwartet und stattdessen etwas in einer 1-Byte-ISO-Codierung bekommt.

Db ist auf utf8 german2 formatiert.

Auch hier muss man fragen: Und was steht wirklich drin?

OK Fehler gefunden. DAtenbank war OK, Seite war ok, nur die DB Verbindung war falsch. Nun scheint es zu gehen.

Na also. Wichtig ist, dass man von Anfang bis Ende dieselbe Zeichencodierung verwendet. Und da, wo es unbedingt mal etwas anderes als UTF-8 sein muss (warum auch immer), muss man explizit umcodieren. Dabei besteht dann das Risiko, dass bestimmte Zeichen unter die Räder kommen, weil sie in der Zielcodierung nicht darstellbar sind.

Einen schönen Tag noch
 Martin

[Auge]

Hallo

Wird schwierig, da es erstmal nur im xampp läuft. Es ist keine Seite im eigendlichen Sinn, sondern eine Webanwendung.

Warum du nun aber eine Reihe von Zeilenumbrüchen ins Dokument schreibst, solltest du uns auch ohne für uns bereitgestellten Code erklären können. Falls und wenn ich mit meiner Vermutung recht habe, hat auch @MudGuard mit seinem Einwurf, dass das prinzipbedingt so nichts werden kann, recht ^[1].

Wie gesagt, es gibt dafür richtige™️ Lösungen in CSS.

Tschö, Auge

---

1. Ja, auch dann, wenn es sich um eine Webanwendung handelt, die unter kontrollierteren Bedingungen als eine Website angezeigt wird. ↩︎

[MudGuard]

Hi,

hat auch @MudGuard mit seinem Einwurf, [...] recht [^1].

Ich habe immer …

.

.

.

… mal wieder Recht! 😉

cu,
Andreas a/k/a MudGuard

[Auge]

Hallo

Ich vermute, dass der Footer von sich aus nicht am unteren Viewportrand sondern direkt unterhalb des Seiteninhalts sitzt, was tsunami mit einer pro Seite unterschiedlichen Anzahl von brs zu beheben sucht.

was aber schon deshalb nicht funktionieren kann, weil die Fenstergröße bei jedem Besucher eine andere ist bzw. sein kann und damit die Anzahl der brs nicht bekannt ist ...

Dann schreibt man halt weit oben „Best viewed with 1024x768 pixels in landscape mode, with font $xyz in the size of 14px and without the browsers bookmarks line, status line, program menu …“ und schick is.

Kann ja nu nich so schwer sein, oder? 😉

Tschö, Auge

[Tabellenkalk]

Hallo,

Dann schreibt man halt weit oben „*Best viewed with ...

Aber mit aol- und yahoo-bar, oder?

Gruß
Kalk

[Auge]

Hallo

Dann schreibt man halt weit oben „*Best viewed with ...

Aber mit aol- und yahoo-bar, oder?

Waren die in irgendeiner Form skalierbar? 😆

Tschö, Auge

[MudGuard]

Hi,

Dann schreibt man halt weit oben „Best viewed with 1024x768 pixels in landscape mode, with font $xyz in the size of 14px and without the browsers bookmarks line, status line, program menu …“ und schick is.

Ich hatte auch mal so einen Best-Viewed-Gif auf meiner Seite:

Best viewed with open eyes!

😉

cu,
Andreas a/k/a MudGuard

[Rolf B]

Hallo tsunami,

ich habe deinen Code ein bisschen formatiert. Dein HTML ist allerdings gruselig.

• Das ist keine Überschrift. <h*> Elemente nur wegen der damit verbundenen Default-Styles zu verwenden ist nicht korrekt.
• Abstände definiert man im CSS per Margin. Nicht per <br><br><br>. Brrrr.
• Das Nachprogrammieren von Browserfunktionen ist nicht sinnvoll. Der Zurück-Button ist schon da Sorry, in einer Fullscreen-Anwendung ist das was anderes.
• &uuml; & Co sind bei korrekt verwendeter Codierung im Sourcecode überflüssig. UTF-8 ist das Encoding des Web.

Dein Problem resultiert aus einem cache-limiter, der dynamisch erzeugte Seiten clientseitig cached. Das ist grundsätzlich untauglich. GET Requeste werden vom Browser (oder einem zwischengelagerten Proxy) zwischengespeichert, weil es zur Semantik von GET gehört, dass die gelieferten Daten stabil bleiben. Wenn Du aber Daten anzeigst, die sich von einem Abruf zum anderen ändern können, darfst Du nicht cachen.

Die richtige Lösung ist der Verzicht auf Caching und der Einsatz des PRG-Pattern - d.h. Posts ändern lediglich die Datenbank und enden dann mit einem Redirect. Die Anzeige erfolgt ausschließlich im GET. Für den Redirect nimmt man häufig den HTTP Status 302 (Found) - die 303 (See Other) ist aber auch sinnvoll.

Rolf

[Der Martin]

Hallo Rolf,

interessant, wie wir unabhängig voneinander dieselben Kritikpunkte herausgearbeitet haben. 😉

Einen schönen Tag noch
 Martin

[Rolf B]

Hallo Martin,

wir sind offenbar ähnlich drauf. Wir sollten einen Verein gründen!

Ach verdammt. Ich bin ja schon drin…

Rolf