DrJekyll98: Perl Script- Website aufrufen

Ich habe folgendes Problem: Ich erstelle zur Zeit HTML-Seiten und benutze auch Perl-Scripts. Da die Seiten desöfteren Eingabezeilen und oder radio-buttons haben, welche mit submit-buttons abgesendet werden, habe ich ein Problem mit dem weiterkommen auf die nächste HTML-Seite...

Ich habe herausgefunden, dass wenn man am Ende des Perl-Programms folgendes(X1) schreibt, wird eben diese Seite als nächste Seite angezeigt.

X1: 
print "Content-type: text/html\n\n";

print '<html>';

print '<body>';

print "<p>Danke.</p>";

print '</body>';

print '</html>';

__Ende__

Würde ich das allerdings jedesmal genau so machen, müsste ich scheinbar für jede Seite ein neues Perl-Script schreiben, welches den Quelltext der nächsten Seite beinhaltet...

Hier meine Frage: Wäre es irgendwiemöglich, dass ich die nächste HTML-Seite als .html-Datei erstelle und anstatt den gesamten Quelltext ins Perl-Script zu schreiben, einfach den Name der .html-Datei angebe ?

Danke im Vorraus, VG

  1. Hallo,

    Ich habe folgendes Problem:

    ... dir fehlt das Grundlagenwissen, wie die Browser-Server-Kommunikation, also HTTP, funktioniert.

    Ich erstelle zur Zeit HTML-Seiten und benutze auch Perl-Scripts. Da die Seiten desöfteren Eingabezeilen und oder radio-buttons haben, welche mit submit-buttons abgesendet werden, habe ich ein Problem mit dem weiterkommen auf die nächste HTML-Seite...

    Solltest du eigentlich nicht. Du hast also ein HTML-Dokument mit einem Formular, das beim Absenden ein Script auf dem Server aufruft. Das Script wird ausgeführt, tut irgendwas mehr oder weniger Sinnvolles mit den übermittelten Formulardaten, und schickt eine Antwort (Response) an den Browser zurück. Das ist der prinzipielle Ablauf.

    Ich habe herausgefunden, dass wenn man am Ende des Perl-Programms folgendes(X1) schreibt, wird eben diese Seite als nächste Seite angezeigt.

    X1: 
    print "Content-type: text/html\n\n";
    print '<html>';
    print '<body>';
    print "<p>Danke.</p>";
    print '</body>';
    print '</html>';
    
    __Ende__
    

    Genau. Das ist die HTTP-Antwort deines Scripts. Eine Headerzeile, die den Typ der Antwort angibt (hier: ein HTML-Dokument), und dann eine Leerzeile und der Nutzinhalt.

    Würde ich das allerdings jedesmal genau so machen, müsste ich scheinbar für jede Seite ein neues Perl-Script schreiben, welches den Quelltext der nächsten Seite beinhaltet...

    Natürlich. Die Verarbeitung der übergebenen Daten ist doch vermutlich auch jedesmal anders, oder?

    Hier meine Frage: Wäre es irgendwiemöglich, dass ich die nächste HTML-Seite als .html-Datei erstelle und anstatt den gesamten Quelltext ins Perl-Script zu schreiben, einfach den Name der .html-Datei angebe ?

    Jein. Du kannst zwar auf eine andere Ressource weiterleiten, also ein reines statisches HTML-Dokument, indem du einen Location-Header sendest (PHP setzt dann automatisch auch den richtigen HTTP-Status, keine Ahnung, ob Perl das auch macht). Aber welchen Sinn hätte das? Dann wäre die Antwort auf jede Aktion, jedes Formular exakt identisch. Nicht wirklich, oder?

    Danke im Vorraus,

    Das 'r' gab's im Doppelpack wohl billiger?

    So long,
     Martin

    --
    Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
    - Douglas Adams, The Hitchhiker's Guide To The Galaxy
    1. @@Der Martin

      Das 'r' gab's im Doppelpack wohl billiger?

      Und Leerzeichen gibt’s wohl für umme?

      Das würde erklären, warum so viele Deppen Leer Zeichen gesetzt werden. So etliche von ihnen schaffen es ins Fernsehen.

      LLAP 🖖

      --
      “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
      Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
      1. Hallo Gunnar,

        Das 'r' gab's im Doppelpack wohl billiger?

        Und Leerzeichen gibt’s wohl für umme?

        komm, sei fair, es war nicht so schlimm, wie schon in manchen anderen Beiträgen.

        Das würde erklären, warum so viele Deppen Leer Zeichen gesetzt werden. So etliche von ihnen schaffen es ins Fernsehen.

        Wundert dich das? Wo doch die Werbe- und Marketingindustrie ihr Bestes gibt, immer neue dämliche Produktbezeichnungen mit Deppenleerzeichen zu kreieren?

        Da gibt es einen Automobilkonzern, der trotz aller Abgasskandale noch stolz "Volkswagen Original Teile" anbietet; da gibt es einen Marmeladenhersteller aus Hedwig-Holzbein, der "Himbeer Konfiture" anpreist; da gibt es diverse Technik-Firmen, die "Handy Tarife" im Angebot haben. Ist es da noch verwunderlich, dass derartiger Unsinn sich auch in der Bevölkerung durchsetzt?

        So long,
         Martin

        --
        Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
        - Douglas Adams, The Hitchhiker's Guide To The Galaxy
        1. @@Der Martin

          komm, sei fair, es war nicht so schlimm, wie schon in manchen anderen Beiträgen.

          Ich wollte mich hier gart nicht auf das OP beziehen.

          Wundert dich das? Wo doch die Werbe- und Marketingindustrie ihr Bestes gibt, immer neue dämliche Produktbezeichnungen mit Deppenleerzeichen zu kreieren?

          „Ey Alter, voll das Waschmittel!“ [@deppenleerzeich]

          Früher™ was alles besser. Jedenfalls bei uns™.

          LLAP 🖖

          --
          “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
          Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
          1. irgendwiemöglich

            Nee, im OP waren Leer Zeichen mit Auf Preis versehen :-D

            Rolf

    2. Die Frage ist doch, wie Dr. Jekyll sich das vorgestellt hat. "Eine .html Datei erstellen und dann includen" - das muss doch nicht bedeuten dass die .html Datei statisch ist. Das Perl Script kann sie während seines Ablaufs erzeugt haben.

      Ob das mit Perl geht - keine Ahnung. Im blödesten Zweifelsfall genauso wie das von mir vermutete Erstellen: Datei auf, while not eof() { Read, Print }, Datei zu, Datei löschen. Wie man das auf Perl erzählt, muss jemand anderes sagen :). Einen HTTP Redirect würde ich jedenfalls für die schlechteste Lösung halten, denn dann muss die Datei den Request überleben und steht nachher als traurige Leiche herum.

      ALLERDINGS - dieser Ablauf ist problembefrachtet. Denn auf einem Webserver kann eine Menge Besucherverkehr herrschen, und je nach Serversoftware wird auch gerne mal mehr als ein Request gleichzeitig verarbeitet. Wenn ein Script in diesem Umfeld eine temporäre Datei aufbauen will, um sie am Ende auf den Antwortstream zu kopieren, entsteht ein Konflikt, weil zwei Script-Instanzen die gleiche Datei schreiben wollen. Bevor Dir der Kurgan deswegen den Kopf abschlägt, musst Du für solche Aktionen einen temporären Dateinamen erzeugen, der pro Request eindeutig ist. In PHP gibt's dafür Funktionen wie tempnam oder tmpfile, was Perl hier zu bieten hat weiß ich nicht.

      Unterm Strich bleibt daher das Fazit: Lass es. Es ist guter Brauch auf dem Webserver, nach Möglichkeit alle Aktivitäten im Arbeitsspeicher auszuführen bzw. persistente Daten in Datenbanken zu halten, und dann die Antwortseite an Hand der Arbeitsspeicherdaten zu erzeugen. Temp-Dateien erzeugt man nur, wenn ansonsten der RAM explodieren würde.

      Rolf

    3. Danke im Vorraus,

      Das 'r' gab's im Doppelpack wohl billiger?

      Die gab es grratis, habe noch den ganzen Kellerr voll ;)

    4. Würde ich das allerdings jedesmal genau so machen, müsste ich scheinbar für jede Seite ein neues Perl-Script schreiben, welches den Quelltext der nächsten Seite beinhaltet...

      Natürlich. Die Verarbeitung der übergebenen Daten ist doch vermutlich auch jedesmal anders, oder?

      Ich hätte den Namen der HTML-Seite, welche aufgerufen werden soll, als String bzw. Variable übergeben wollen, den Inhalt des Strings bzw. der Variable dann mit param('...') aus der aktuellen HTML-Seite geholt

  2. Hier meine Frage: Wäre es irgendwiemöglich, dass ich die nächste HTML-Seite als .html-Datei erstelle und anstatt den gesamten Quelltext ins Perl-Script zu schreiben, einfach den Name der .html-Datei angebe ?

    Natürlich. Erstelle die .html Datei als Template mit entsprechenden Platzhaltern und setze ein Template-System ein wie z.b. HTML::Template.

    MfG

  3. Ich habe folgendes Problem: Ich erstelle zur Zeit HTML-Seiten und benutze auch Perl-Scripts.

    Da Du Perl (noch) nicht kannst (sonst hättest Du mindestens heredoc verwendet und Deine HTML-Datei eingelesen) und offenbar ausschließlich Webseiten erzeugen lassen willst: Überlege ob PHP für Dein Ansinnen nicht die bessere Wahl ist.

    Argumente:

    • PHP ist dafür gedacht, vieles was PHP ab Werk kann musst Du in Perl erst importieren oder selbst programmieren.
    • Perl ist schwieriger und, jedenfalls für Anfänger, schlechter dokumentiert.
    1. PHP ist total rückständig. Das zeigt sich u.a. an der mangelhaften UTF-8-Unterstützung die bereits mit Perl v5.6 (2001) gegeben war.

      Und es ist gerade der Modulare Aufbau von Perl, mit ca. 100 Built-In-Funktionen auszukommen, womit Perl modernen Anforderungen wie Data-Access-Layer u.a. Schichtenmodelle viel besser gerecht wird als PHP.

      #!Perl was sonst

      1. Tach!

        Und es ist gerade der Modulare Aufbau von Perl, mit ca. 100 Built-In-Funktionen auszukommen, womit Perl modernen Anforderungen wie Data-Access-Layer u.a. Schichtenmodelle viel besser gerecht wird als PHP.

        Könntest du bitte diese Behauptung mit nachvollziehbaren Argumenten untermauern? Inwiefern soll es PHP an einer Modularität fehlen, die nötig wäre, um die angesprochenen Dinge "viel besser" programmieren zu können?

        dedlfix.

        1. Also ich würde ja ohnehin ASP.NET MVC bevorzugen. Es gibt übrigens auch LISP-Webserver!

          Und Erweiterungszoos gibt es für Perl, PHP und wasweißichnoch genügend.

          1. Also ich würde ja ohnehin ASP.NET MVC bevorzugen.

            Alternativ-Text

            Das Bild zeigt, warum ich das nicht machen würde.

            1. Also ich würde ja ohnehin ASP.NET MVC bevorzugen.

              Alternativ-Text

              Das Bild zeigt, warum ich das nicht machen würde.

              Ein enorm finanzstarker und technisch-erfahrener Maintainer hält dich davon ab ein OpenSource-Projekt zu benutzen? Das ist kein besonders erleuchtendes MS-Bashing.

              1. Ihr habt das Humor-Tag aber gesehen? :)

                1. Tach!

                  Ihr habt das Humor-Tag aber gesehen? :)

                  Ich nicht, weil ich nämlich tatsächlich ASP.NET MVC bevorzuge, wenn der IIS als Plattform zur Verfügung steht. Das Entwickeln und vor allem Debuggen im Visual Studio empfinde ich als angenehmer als mit Kontrollausgaben in PHP zu hantieren.

                  dedlfix.

                  1. Ich nicht, weil ich nämlich tatsächlich ASP.NET MVC bevorzuge, wenn der IIS als Plattform zur Verfügung steht. Das Entwickeln und vor allem Debuggen im Visual Studio empfinde ich als angenehmer als mit Kontrollausgaben in PHP zu hantieren.

                    Der Fairness halber muss man sagen, dass es für PHP auch Debugger gibt, die sind nur leider nicht Teil des des Zend-JIT-Compilers sondern müssen auf andere Weise nachgerüstet werden. Das ist keine schöne Arbeit, aber in aller Regel die Mühe wert.

    2. Ich habe folgendes Problem: Ich erstelle zur Zeit HTML-Seiten und benutze auch Perl-Scripts.

      Da Du Perl (noch) nicht kannst (sonst hättest Du mindestens heredoc verwendet und Deine HTML-Datei eingelesen) und offenbar ausschließlich Webseiten erzeugen lassen willst: Überlege ob PHP für Dein Ansinnen nicht die bessere Wahl ist.

      JavaScript sollte auch immer eine Überlegung wert sein. Es ist (zusammen mit HTML und CSS) der kleinste gemeinsame Nenner, den jeder Fullstack-Entwickler beherrschen muss - das betrifft Clientcode, Servercode und Tooling. Außerdem hat es unter allen Programmiersprachen gegenwärtig das Ökosystem mit der größten Ausprägung und eine sehr zufriedene und engagierte Community (vgl. Stackoverflow Develoepr Survey 2016 und GitHub-Aktivität). Gerade Programmieranfängern würde ich heute JavaScript empfehlen, ein paar wesentliche Gründe dafür sind:

      • Der Sprachkern ist sehr schmal und konsistent.
      • Es gibt sehr viele Dialekte, in die man eintauchen kann. Das ermöglicht es sehr schnell Erfahrungen mit verschiedenen Programmierstilen zu sammeln.
      • Man kann ab Tag 1 produktiv sein.

      Auch wenn Trends in unserer Branche oft nur kurzlebig sind, deutet vieles daraufhin, dass JavaScript seine Relevanz in den nächsten Jahren noch ausbauen wird. PHP ist nach meinem Empfinden bereits auf einem absteigenden Ast, das legt auch die Stackoverflow-Umfrage nahe, in der es heißt:

      More people use JavaScript than use any other programming language. PHP appears to be falling out of favor as Node and Angular emerge.

      Wie auch immer, WebAssembly könnte in nicht allzu ferner Zukunft nochmal ein Gamechanger werden, es könnte aber auch ein weiterer Katalysator zu Gunsten von JS werden.

  4. Erstmal danke für die vielen Antworten,

    Vom Prinzip her geht es mir nur darum, nach dem Betätigen des Submit-Buttons auf die nächste Seite zu kommen... mehr will ich nicht :(

    Wenn es so nicht funktioniert, wie ich es gedacht habe, kennt jmd. einen oder evtl. auch zwei andere Lösungsansätze?

    VG

    1. Entweder schreibst Du tatsächlich für jede Seite ein Script, und trägst im Form der Seite n als Action den Namen des Scripts für Seite n+1 ein. Das Script für Seite n+1 muss im Stande sein, die Formdaten von Seite n zu verarbeiten, ggf. die Daten der Seiten 1-(n-1) mit in Betracht zu ziehen und daraus das HTML für die Seite n+1 zu generieren.

      Oder du verwendest eine erweiterte Action und schreibst am Form action="hurz.pl?seite=2", mit jeweils passender Seitennummer, und hast dann EIN Perl-Script, dass diesen Parameter interpretiert und dann die jeweilige Seite erzeugt. Die Aufgabe an sich bleibt unverändert, sie wird nur nicht auf X Scripte verteilt.

      Das eigentliche Erzeugen kannst Du mit der Hand am Arm ins Perl hineinhacken, so wie im OP, und dabei versuchen, den Teil, der auf jeder Seite identisch ist, durch gemeinsamen Code zu erzeugen. Oder Du verwendest eine Template-Library (Grobdefinition Template=Vorlagentext mit Lücken, die aus Variablen gefüllt werden). Dafür gab es oben Hinweise; ich selbst habe keine Ahnung was es für Perl gibt. In PHP würde ich Dir Smarty als ein MÖGLICHES Templatesystem vorschlagen.

      Arbeit ist es jedenfalls immer.

      Rolf

    2. Tach!

      Vom Prinzip her geht es mir nur darum, nach dem Betätigen des Submit-Buttons auf die nächste Seite zu kommen... mehr will ich nicht :(

      Was ist denn das eigentliche Ziel? Soll der Submit-Button ein Formular mit Daten darin zur Verarbeitung an den Server senden, oder fungiert der Submit-Button nur als ein Element, um zu einer anderen Seite zu kommen, mithin also als ein Link? Wenn Link, dann nimm einen Link. Der macht genau das was du willst, ohne weitere Kopfstände.

      Im Falle des Formulars mit Daten wäre eine Technik namens Affenformular die voraussichtlich bessere Wahl. Dabei wird das Formular immer wieder zu sich selbst gesendet. Erst wenn die serverseitige Verarbeitung die Korrektheit festgestellt hat und das getan hat, was mit den Daten geschehen soll (Eintrag in Datenbank zum Beispiel), gibt es als Antwort ein Redirekt zur Folgeseite.

      dedlfix.

      1. Hi,

        Vom Prinzip her geht es mir nur darum, nach dem Betätigen des Submit-Buttons auf die nächste Seite zu kommen... mehr will ich nicht :(

        Was ist denn das eigentliche Ziel? Soll der Submit-Button ein Formular mit Daten darin zur Verarbeitung an den Server senden, oder fungiert der Submit-Button nur als ein Element, um zu einer anderen Seite zu kommen, mithin also als ein Link? Wenn Link, dann nimm einen Link. Der macht genau das was du willst, ohne weitere Kopfstände.

        Beides, er soll zum einen die Daten senden und dann soll er auf die nächste Seite weiterleiten... VG

        1. Tach!

          Beides, er soll zum einen die Daten senden und dann soll er auf die nächste Seite weiterleiten...

          Dann nimm die Affenformular-Technik.

          dedlfix.

        2. Beides, er soll zum einen die Daten senden und dann soll er auf die nächste Seite weiterleiten...

          • Die Daten sind welchen Inhalts?
          • Das Skript macht bitte was?
          • Und die nächste Seite beinhaltet was?
          1. Inhalt der Daten an Script: welche Auswahl wurde bei Radiobuttons getroffen Script: Auswahl richtig oder falsch, schreibt "1" oder "0" in eine .txt-Datei Inhalt nächste Seite: neu Radiobuttonauswahl

    3. Erstmal danke für die vielen Antworten,

      Vom Prinzip her geht es mir nur darum, nach dem Betätigen des Submit-Buttons auf die nächste Seite zu kommen... mehr will ich nicht :(

      Unter demselben URL wäre da nur ein anderes Template zu laden. Also auch dasselbe Script, was dahinter steckt. In der Serverumgebung SCRIPT_NAME oder, wenn du mit mod_rewrite arbeitest REDIRECT_URL. In letzterem Fall ist das der Default für das aktion= Attribut, so Du das auch weglassen kannst.

      Beispiel einer solchen Anwendung mit Perl-Code

      Schönes Wochenende!

      1. Tach!

        Vom Prinzip her geht es mir nur darum, nach dem Betätigen des Submit-Buttons auf die nächste Seite zu kommen... mehr will ich nicht :(

        Unter demselben URL wäre da nur ein anderes Template zu laden. Also auch dasselbe Script, was dahinter steckt.

        Technisch kann man das so machen, dass alle Vorgänge nacheinander unter derselben URL stattfinden. Man muss sich dann aber auch bewusst sein, beziehungsweise sollte das bei der Empfehlung als Nebenwirkung nennen, dass dann natürlich keine einzelnen Vorgänge direkt per Bookmark oder Link angesprungen werden können. Auch das Bewegen durch die Browserhistory fällt damit flach. Wenn man das nicht braucht, mag das ok sein.

        dedlfix.

        1. Tach!

          Vom Prinzip her geht es mir nur darum, nach dem Betätigen des Submit-Buttons auf die nächste Seite zu kommen... mehr will ich nicht :(

          Unter demselben URL wäre da nur ein anderes Template zu laden. Also auch dasselbe Script, was dahinter steckt.

          Technisch kann man das so machen, dass alle Vorgänge nacheinander unter derselben URL stattfinden. Man muss sich dann aber auch bewusst sein, beziehungsweise sollte das bei der Empfehlung als Nebenwirkung nennen, dass dann natürlich keine einzelnen Vorgänge direkt per Bookmark oder Link angesprungen werden können. Auch das Bewegen durch die Browserhistory fällt damit flach. Wenn man das nicht braucht, mag das ok sein.

          Hä!? Erzähl das bloß keinen, so ein Stuss. Selbstverständlich funktioniert da die History und mit der Default-Method GET gibts sogar ganz echte URLs zum Verschenken.

          Linkbeschreibung

          1. Hallo,

            Unter demselben URL wäre da nur ein anderes Template zu laden. Also auch dasselbe Script, was dahinter steckt.

            [...] dass dann natürlich keine einzelnen Vorgänge direkt per Bookmark oder Link angesprungen werden können. Auch das Bewegen durch die Browserhistory fällt damit flach. Wenn man das nicht braucht, mag das ok sein.

            Hä!? Erzähl das bloß keinen, so ein Stuss. Selbstverständlich funktioniert da die History und mit der Default-Method GET gibts sogar ganz echte URLs zum Verschenken.

            also was nun? Dieselben URLs, oder doch verschiedene?
            Meinst du vielleicht: Dasselbe Script, aber mit verschiedenen URL-Parametern? Das sind dann aber verschiedene URLs.

            So long,
             Martin

            --
            Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
            - Douglas Adams, The Hitchhiker's Guide To The Galaxy
          2. Tach!

            Technisch kann man das so machen, dass alle Vorgänge nacheinander unter derselben URL stattfinden. Man muss sich dann aber auch bewusst sein, beziehungsweise sollte das bei der Empfehlung als Nebenwirkung nennen, dass dann natürlich keine einzelnen Vorgänge direkt per Bookmark oder Link angesprungen werden können. Auch das Bewegen durch die Browserhistory fällt damit flach. Wenn man das nicht braucht, mag das ok sein.

            Hä!? Erzähl das bloß keinen, so ein Stuss. Selbstverständlich funktioniert da die History und mit der Default-Method GET gibts sogar ganz echte URLs zum Verschenken.

            Der OP hat in einem seiner Postings verlauten lassen, dass POST zum Einsatz kommt. Somit hat er keine unterschiedlichen sondern die von dir genannte selbe URL. Deine Empfehlung war auch nicht, auf GET umzusteigen. Damit wäre aber auch nicht automatisch gegeben, dass die ausgefüllten Formulare stets unterschiedliche URLs erzeugen.

            In dem Punkt mit der Browserhistory habe ich mich offensichtlich geirrt, und sowas kann man auch mit weniger aggressiven Worten kundtun. Jedenfalls hatte ich hier ein anderes Verhalten in Erinnerung als ich grad eben beim Nachvollziehversuch erhielt. Entweder haben sich die Browser in dem Punkt geändert, oder meine Erinnerung ist falsch. Die einzelnen POSTs landen doch separat in der History, sogar unterschiedliche Daten bleiben zu sehen. Hatten die Browser nicht früher mal nur jeweils einmal Inhalt pro URL im Cache behalten?

            dedlfix.

    4. Erstmal danke für die vielen Antworten,

      Vom Prinzip her geht es mir nur darum, nach dem Betätigen des Submit-Buttons auf die nächste Seite zu kommen... mehr will ich nicht :(

      Extra für Dich: Eine DEMO dem Auftrag entsprechend und guck mal in den Perl-Code (ist da verlinkt) wie wenig das ist wenn Du nur die richtigen Ideen hast ;)

      1. Hallo pl!

        Extra für Dich: Eine DEMO dem Auftrag entsprechend und guck mal in den Perl-Code (ist da verlinkt) wie wenig das ist wenn Du nur die richtigen Ideen hast ;)

        Deine Seite ist leider anfällig für XSS-Angriffe, weil du den Kontextwechsel nach HTML missachtest.

        Viele Grüße

        1. Deine Seite ist leider anfällig für XSS-Angriffe, weil du den Kontextwechsel nach HTML missachtest.

          Hm. Solche Vorwürfe sollte man belegen. Test.

          Ergebnis: "Ihre Eingabe: <script type="text/javascript">alert("XSS");</script>"

          Diesen XSS-Angriff hat das Skript bestanden. Was und wie hast Du getestet?

          1. Was und wie hast Du getestet?

            Ähnlich wie du, worauf hin diese Warnung im meinem Browser aufgetaucht ist:

            The XSS Auditor refused to execute a script in 'http://perl.rolfrost.de/formswitch.html?in=%3Cscript%3Econfirm%28%27Kontextwechsel+beachten%21%27%29%3B%3C%2Fscript%3E&sw=1' because its source code was found within the request. The auditor was enabled as the server sent neither an 'X-XSS-Protection' nor 'Content-Security-Policy' header.
            

            pl hat den Fehler aber wie es scheint sehr schnell behoben 👍

  5. Hallo, nach langem Überlegen und unter anbetracht des begrenzten Zeitraums habe ich mich nun für die unästhetischere Variante entschieden: Ich lasse vom Perl-Script immer eine html-Seite erstellen, wo nur der Link zur eigentlichen nächsten Seite angezeigt wird. So wird immer das gleiche Perl-Script verwendet (nur der Link wird eben mit param von der vorhergehenden Seite aus einer versteckten Zeile (hide) im Quelltext entnommen. Ich danke allen für ihre Bemühungen, mir die Problematik verständlich zu erklären (mehr oder weniger :D). Sollte ich am Ende noch genügend Zeit zur Verfügung haben, werde ich mich selbstverständlich einer schöneren Lösung dieses kleinen Problems widmen.

    VG