HTML-Code wird nicht ausgeführt sondern nur als Text angezeigt

[Pits]

Hi folks,

habe ein (für euch wohl banales) problem: ich lese die komplette html-datei aus einer data-datei ein, ersetze gewisse zeichenfolgen durch variablen und printe die html-statements. so sieht das ganze aus:

#-----------------------------------------------------------------------------#

DATA-Array zeilenweise abarbeiten, allfällige Variablen ersetzen und printen#

#-----------------------------------------------------------------------------#
$i=0;
foreach (@data_file) {
  if ($_ =~ m/~link~/) {
  $temp = $db_content[$i];
    $db_content[$i] =~ s/ /_/;
    $_ =~ s/~link~/<a href="/$db_content[$i]/$db_content[$i].pl" target="_self">$temp</a>/;
    $i++;
  }
  print $_;
}

• in @data_file sind alle html-zeilen
• in @db_content sind die variablen

Das problem ist nun, dass die ganze html-seite wohl angezeigt wird, aber nicht übersetzt! das heisst ich seh im browser den gesamten code!
warum übersetzt der browser nix?

danke!

[Nabraham]

Das problem ist nun, dass die ganze html-seite wohl angezeigt wird, aber nicht übersetzt! das heisst ich seh im browser den gesamten code!

Wenn eine HTML-Datei als Textdatei angezeigt wird, dann liegt dies schlichtweg daran, dass der Server dem Browser mitteilt, es handele sich um eine Textdatei (text/plain). Schicke die richtige Content-Type:-Angabe (text/html).

[Skrilax]

Hi!

Schicke die richtige Content-Type:-Angabe (text/html).

Am sichersten mit dem CGI-Modul:

  
use CGI 'header';  
  
print header();  
  
print $den_ganzen_Rest;  

Grüße, Skrilax.

[Beat]

Am sichersten mit dem CGI-Modul:

Ich halte es für einen sinnlosen Overhead, für eine Zeile cgi.pm zu verwenden. Dein Vorschlag hat mit Sicherheit nichts zu tun.

[Skrilax]

hallo!

Dein Vorschlag hat mit Sicherheit nichts zu tun.

Klar, dass man damit keinen Virenschutz erhält oder so. Ich meinte damit auch die Sicherheit vor fiesen Tipp- und vergessene-Zeilenumbrüche-Fehlern. ;-)

Und möglich, das es hier nicht lohnt. Aber meistens braucht man das CGI-Modul ja sowieso, wenn man dynamische Webseiten entwickelt. Ich wollte den Fragesteller deswegen auf diese Möglichkeit hinweisen.

Grüße, Skrilax.

[Beat]

Dein Vorschlag hat mit Sicherheit nichts zu tun.

Klar, dass man damit keinen Virenschutz erhält oder so. Ich meinte damit auch die Sicherheit vor fiesen Tipp- und vergessene-Zeilenumbrüche-Fehlern. ;-)

Ich halte Transparenz für sicherer. cgi.pm dient nicht der Transparenz sondern stellt eine API zwischen HTML und perl

Und möglich, das es hier nicht lohnt. Aber meistens braucht man das CGI-Modul ja sowieso, wenn man dynamische Webseiten entwickelt.

_Man_ braucht überhauüpt kein cgi.pm für das erstellen von dynamischen Webseiten. cgi.pm vermittelt des öfteren falsche Vorstellungen über HTML, verbirgt sicherheitsrelevante Vorgänge und braucht unnötig viel Speicher, vor allem dann, wenn man das HTML Angebot nutzen will.
cgi.pm nimmt dir nicht die Aufgabe ab, User-Inputs zu legalisieren.
Meiner Ansicht nach ist cgi.pm für dummies geschriebn und widerspricht dem Self-Charakter, dessen Kern ja der Lerneffekt und die Einsicht in die Vorgänge ist.

Ich wollte den Fragesteller deswegen auf diese Möglichkeit hinweisen.

Dann mache ihn auch auf die Problematik desselben aufmerksam...
Wer sein Script einem Modul anvertraut, ist auf die Aktualisierung des Moduls angewiesen. Wer die Invasion seines Scripts durch ein Modul bereits vorgenommen hat, wird dies kaum mehr rückgängig machen.

mfg Beat

[Skrilax]

Ich halte Transparenz für sicherer. cgi.pm dient nicht der Transparenz sondern stellt eine API zwischen HTML und perl

hmm, ja, auch.

Meiner Ansicht nach ist cgi.pm für dummies geschriebn und widerspricht dem Self-Charakter, dessen Kern ja der Lerneffekt und die Einsicht in die Vorgänge ist.

Na, diese Einstellung halte ich dann doch für n bissl extrem ;-)
Grad bei der korrekten Entgegennahme von POST- und GET-Parametern nimmt CGI doch ne Menge arbeit ab. Das man diese entsprechend der aktuellen Begebenheiten noch kontrollieren muss (v.a. beim Dateiupload) ist klar (wenn vlt. auch nicht jedem, das gebe ich zu...).

Für den Output, sprich den html-code, verwende ich CGI auch nicht, da halte ich mich lieber an Templates, um html und Skript komplett zu trennen. Erleichtert die Pflege des ganzen deutlich, wie ich finde.

Wer sein Script einem Modul anvertraut, ist auf die Aktualisierung des Moduls angewiesen.

Gegenargument: Wer sein Skript einem _Standard_modul anvertraut, weiß dass dieses von Experten geschrieben und schon von zig Leuten getestet und verbessert wurde. Grad bei sicherheitsrelevanten Anwendungen (z.B. Sessions) halte ich das dann wohl für den besseren Weg, als da auf Zwang was Eigenes zu schreiben, und dabei zig Sicherheitslücken zu übersehen.

Grüße, Skrilax

[Pits]

Hi,
Danke bis jetzt für die Tips, sie haben leider nix genützt! Ich schicke den Content-Typ korrekt rüber:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html">
  <title>FUST AG, Bauunternehmung</title>
  <link rel="stylesheet" type="text/css" href="/formate.css">
</head>

Besonders interessant ist, dass der Internet Explorer 7 die Website aufbereitet, der Firefox jedoch nur den (korrekten und vollständigen) HTML-Code anzeigt...

any ideas?

thanx

[DeWitt]

Hallo SELFHTML-Gemeinde,

Danke bis jetzt für die Tips, sie haben leider nix genützt! Ich schicke den Content-Typ korrekt rüber:
[...]

Es nützt nichts, wenn du erst im Content angibst, dass es ein HTML-Dokument ist. Normalerweise sollte deine erste Ausgabe an den Browser die Zeile
print "Content-type: text/html\n\n";
sein, die als Teil des <http://de.selfhtml.org/perl/sprache/cginotwendig.htm@title=CGI-notwendigen HTTP-Headers> den richtigen Content-Type definiert.

Ciao,
David //aka DeWitt

[Nabraham]

Normalerweise sollte deine erste Ausgabe an den Browser die Zeile
print "Content-type: text/html\n\n";
sein

Nein, wenn schon, dann bitte ganz richtig (und in die Einzelteile aufgeschlüsselter, damit die Zusammenhänge klarer werden):

print "Content-Type: text/html\r\n";
print "\r\n";

[Struppi]

Nein, wenn schon, dann bitte ganz richtig (und in die Einzelteile aufgeschlüsselter, damit die Zusammenhänge klarer werden):

print "Content-Type: text/html\r\n";
print "\r\n";

Das ist aber auch nicht richtig das \n ist ein OS abhängiger Zeilenumbruch. Daher ist am sinnvollsten, wie meistens, ein passendes Modul zu verwenden. CGI.pm achtet genau darauf.

Struppi.

[Nabraham]

print "Content-Type: text/html\r\n";
print "\r\n";

Das ist aber auch nicht richtig das \n ist ein OS-abhängiger Zeilenumbruch.

Perl ersetzt \n durch \n, \r\n oder \r? Was ist denn das für ein Mist? \n ist mir bislang immer als Zeilenvorschub (ASCII-Zeichen 10) untergekommen, nie als ein "Kommt-drauf-an-Zeilenumbruch". Wie gibt man in Perl denn sicher den Zeilenvorschub aus, mit \x0a?

Javascript ist toll (Perl auch!)

Kann ich für Perl jetzt gerade nicht nachvollziehen.

[Struppi]

print "Content-Type: text/html\r\n";
print "\r\n";

Das ist aber auch nicht richtig das \n ist ein OS-abhängiger Zeilenumbruch.

Perl ersetzt \n durch \n, \r\n oder \r? Was ist denn das für ein Mist? \n ist mir bislang immer als Zeilenvorschub (ASCII-Zeichen 10) untergekommen, nie als ein "Kommt-drauf-an-Zeilenumbruch". Wie gibt man in Perl denn sicher den Zeilenvorschub aus, mit \x0a?

Naja, für Dateioperatioen ist es wichtig das OS übergreifend ein \n ein Zeilenumbruch ist.

CGI.pm macht das so:

# Define the CRLF sequence.  I can't use a simple "\r\n" because the meaning  
# of "\n" is different on different OS's (sometimes it generates CRLF, sometimes LF  
# and sometimes CR).  The most popular VMS web server  
# doesn't accept CRLF -- instead it wants a LR.  EBCDIC machines don't  
# use ASCII, so \015\012 means something different.  I find this all  
# really annoying.  
$EBCDIC = "\t" ne "\011";  
if ($OS eq 'VMS') {  
  $CRLF = "\n";  
} elsif ($EBCDIC) {  
  $CRLF= "\r\n";  
} else {  
  $CRLF = "\015\012";  
}  
  

Javascript ist toll (Perl auch!)

Kann ich für Perl jetzt gerade nicht nachvollziehen.

Ich schon, du musst dir in Perl über sowas keine Gedanken machen, das ist doch Prima.

Struppi.

[_roro]

Hi,

Danke bis jetzt für die Tips, sie haben leider nix genützt! Ich schicke den Content-Typ korrekt rüber:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01

Sei sogut und guck mal weiter oben, was der Content-Type ist.

Am Besten wir versuchens mal mit einem Helo World CGI:
======================== schnipp ====================
#!/usr/bin/perl

print "Content-Type: text/html\n\n";
print "Helo World\n";
======================== schnapp ====================

Funktioniert das bei Dir?
Und poste mal, was Du so als OS, Webserver und PERL(version) hast.

roro

[Struppi]

Meiner Ansicht nach ist cgi.pm für dummies geschriebn und widerspricht dem Self-Charakter, dessen Kern ja der Lerneffekt und die Einsicht in die Vorgänge ist.

Das ist Quatsch, zu Perl gehört die Verwendung von Modulen und das Wissen, dass es CPAN gibt. dort findest du für jeden Zweck Module, diese nehmen dir viel Arbeit ab und der Lerneffekt ist größer, da du a. dich auf dein Problem konzentrieren kanst b. du Erfahrung im Umgang mit Modulen sammelst, das ist sinnvoller als das Parsen von CGI Parametern zu lernen oder für jedes Projekt HTML Ausgabe Routine zu schreiben. Zumal du es kaum besser kannst, das Modul wird seit 1998 entwickelt, der Autor ergänzt das Modul nach wie vor regelmäßig, ich halte es für ziemlich anmaßend ein Modul, dass seit kanpp 10 Jahren entwickelt wird und von vielen benutzt wird, als für "dummies" geschrieben, zumal deine Kritik sehr unkonkret ist.

Ich wollte den Fragesteller deswegen auf diese Möglichkeit hinweisen.
Dann mache ihn auch auf die Problematik desselben aufmerksam...
Wer sein Script einem Modul anvertraut, ist auf die Aktualisierung des Moduls angewiesen. Wer die Invasion seines Scripts durch ein Modul bereits vorgenommen hat, wird dies kaum mehr rückgängig machen.

Du scheinst noch nicht lange zu programmieren?
In jeder Programmiersprache werden Module, Libaries, Frameworks o.ä eingesetzt, wobei Module dabei noch die unterste Stufe sind und einfach eine Grundlage von Perl ist.

Struppi.

[Pits]

Hi,
Danke bis jetzt für die Tips, sie haben leider nix genützt! Ich schicke den Content-Typ korrekt rüber:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html">
  <title>FUST AG, Bauunternehmung</title>
  <link rel="stylesheet" type="text/css" href="/formate.css">
</head>

Besonders interessant ist, dass der Internet Explorer 7 die Website aufbereitet, der Firefox jedoch nur den (korrekten und vollständigen) HTML-Code anzeigt...

any ideas?

thanx

Hi folks,

habe ein (für euch wohl banales) problem: ich lese die komplette html-datei aus einer data-datei ein, ersetze gewisse zeichenfolgen durch variablen und printe die html-statements. so sieht das ganze aus:

#-----------------------------------------------------------------------------#

DATA-Array zeilenweise abarbeiten, allfällige Variablen ersetzen und printen#

#-----------------------------------------------------------------------------#
$i=0;
foreach (@data_file) {
  if ($_ =~ m/~link~/) {
  $temp = $db_content[$i];
    $db_content[$i] =~ s/ /_/;
    $_ =~ s/~link~/<a href="/$db_content[$i]/$db_content[$i].pl" target="_self">$temp</a>/;
    $i++;
  }
  print $_;
}

• in @data_file sind alle html-zeilen
• in @db_content sind die variablen

Das problem ist nun, dass die ganze html-seite wohl angezeigt wird, aber nicht übersetzt! das heisst ich seh im browser den gesamten code!
warum übersetzt der browser nix?

danke!

[Struppi]

Danke bis jetzt für die Tips, sie haben leider nix genützt! Ich schicke den Content-Typ korrekt rüber:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

Ich sehe keinen content Type
Wie schon erwähnt, du nutzt doch sicher das CGI Modul? dann geb einfach den header aus:
print CGI::header();

und was du vielleicht suchst ist HTML::Template ein Modul das genau das macht was du da vor hast.

Struppi.

[Nabraham]

Danke bis jetzt für die Tips, sie haben leider nix genützt! Ich schicke den Content-Typ korrekt rüber:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html">
  <title>FUST AG, Bauunternehmung</title>
  <link rel="stylesheet" type="text/css" href="/formate.css">
</head>

Wie schon geschrieben wurde, ist da keine verwertbare (!) Content-Type-Angabe drin. Das <meta>-HTML-Element ist wertlos, denn um das <meta>-HTML-Element zu finden, muss der Browser erstmal wissen, dass es sich um HTML handelt (und nicht um einfachen Text oder sonstwas). Diese Angabe steht bei Dir aber im <meta>-HTML-Element, und um das <meta>-HTML-Element zu finden, muss der Browser erstmal wissen, dass es sich um HTML handelt (und nicht um einfachen Text oder sonstwas). Diese Angabe steht bei Dir aber im <meta>-HTML-Element, und um das <meta>-HTML-Element zu finden, ... Ich hoffe, Du erkennst die Endlosschleife.

Der einzige Ort, an dem Du den Browser über den Typ der gesendeten Daten informieren kannst, ist der HTTP-Kopf. Die HTTP-Kommunikation besteht aus zwei Teilen, dem Kopf- und dem optionalen Datenteil. Wie die Daten (also auch Dein HTML-Text oben) interpretiert werden, hängt davon ab, was im Kopf steht, namentlich in der besagten Content-Type-Zeile.

Würdest Du an der Leitung lauschen, solltest Du in etwa folgende Antwort vom Server hören:

HTTP/1.1 200 OK
Content-Type: text/html
[weitere Angaben]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
[Rest vom Fest]

Als Content-Type-Angabe kommt bei Dir statt text/html vermutlich text/plain - und da hilft es dann auch nix mehr, wenn im Text etwas von HTML steht, wenn der Text zuvor als normaler Text und damit ausdrücklich _nicht_ als HTML angekündigt wurde.

Da Du offenbar Firefox auf Deinem Rechner hast, möchtest Du vielleicht seine Erweiterung LiveHTTPHeaders installieren. Nach dem Aufruf einer Webseite wirst Du bei einem Blick in die Seiteninformationen (Menü Extras) eine Karte namens "Header" finden, in der sowohl die gesendeten als auch die empfangenen Kopfzeilen ("Anfrage Header" und "Anwort Header", sic!) aufgeführt sind.

Besonders interessant ist, dass der Internet Explorer 7 die Website aufbereitet, der Firefox jedoch nur den (korrekten und vollständigen) HTML-Code anzeigt...

Der IE hat eine eingebaute Ich-rate-mal-den-Datentyp,-denn-es-gibt-ja-Leute,-die-kennen-sich-mit-dem-Web-nicht-aus-Funktion. Firefox und andere Browser sagen sich hingegen, "Standards sind dazu da, von allen eingehalten zu werden, und wer das nicht oder verkehrt macht, hat halt Pech gehabt."

Das Verhalten des IE ist übrigens ziemlich dumm, denn wolltest Du zu Demonstrationszwecken HTML-Code anzeigen, könntest Du das nicht (bzw. nur, indem Du umständlich den HTML-Code in HTML verpackst), weil der IE eben alles, was entfernt nach HTML riecht, als Webseite anzeigt.