Morgen.
Einem CGIscript werden von einem HTMLFormular Daten submitted. Werden
erfolgreich vom script verarbeitet und anschließend wird ein einfacher
HTMLTeil ausgegeben. Um Letzteren geht es mir hier.
Lokal funktioniert alles wie es soll mit dem laufenden Apache.
Auf meinem Server bei 1&1 ist cgi aktiviert und andere CGISkripte laufen
reibungslos.
Das was lokal funktioniert ist hier aber Essig. Die submitteten Daten
werden erfolgreich verarbeitet, nur der HTMLTeil wird nicht angezeigt.
print("Content-type: text/html\n\n")
...
t_file = open('t.txt','a+', encoding='utf-8')
t_file.write(u"<div>")
t_file.write(u"</div>\n")
t_file.close()
print("<html>")
print("<body>")
print("<p>Übertragung erfolgreich</p>")
print("</body>")
print("</html>")
Habe keine Erklärung. Hat jemand einen Hint oder sagt das jemandem
etwas?
Wieso wird der obere Teil abgearbeitet, aber der HTMLPart nicht?
Matthias schrieb:> print("Content-type: text/html\n\n")
Offizielles Zeilenende von HTTP Headern ist \r\n, nicht \n\n
Und stelle sicher das nach den headern ein weiteres \r\n ausgegeben
wird.
Matthias schrieb:> Wo siehst Du eine Zeile 42?
Nirgendwo. Das ist der Witz. Weil kein Quelltext zu sehen ist. Und somit
niemand die Frage beantworten kann.
Das Beispiel auf SelfHtml ist in Perl geschrieben, da ist print
"Content-type: text/html\n\n"; richtig. Du nutzt aber Python(?), da muss
es lauten:
print("Content-type: text/html")
print()
> Content-type: text/html\n\n
Ist nicht richtig - Es müsste eigentlich eher
>Content-type: text/html\r\n\r\n
sein.
RFC2616 definiert CRLF ("\r\n"), nicht LF ("\n") für die Header -
allerdings funktioniert es meist trotzdem wegen:
"The line terminator for message-header fields is the sequence CRLF.
However, we recommend that applications, when parsing such headers,
recognize a single LF as a line terminator and ignore the leading CR."
Mario M. schrieb:
>print("Content-type: text/html")
bluppdidupp schrieb:
>print("Content-type: text/html\r\n")
optional wg. RFC2616 (so interpretiere ich das)
Stefanus F. schrieb:
>print("Content-type: text/html\r\n\r\n")
Danke für die zahlreichen Hinweise.
Das Problem bleibt aber nach wie vor. Mit den obigen Headern läuft
leider garnichts. Und nocheinmal, wie bereits geschrieben. Was mich
wundert ist der Umstand, dass andere CGISkripte mit dem Header
print("Content-type: text/html\n\n") funktionieren.
Auch bei besagtem Skript wird der erste, in Python3 geschriebene Teil,
ja abgearbeitet. Nur eben nicht die HTMLAusgabe. Das ist das, was ich
mir nicht erklären kann.
Das print von Python gibt automatisch ein '\n' am Ende mit aus (wenn du
das nicht verhinderst)
Das print von perl macht das nicht.
Demnach hat deine html-Ausgabe text/html\r\n\r\n\n
Evtl stört das letzte \n
Die Information der error.log habe ich nicht vergessen. Das Problem, es
wird gar keine angelegt. Der 1&1-Support war heute Nachmittag irgendwie
überfordert und prüft noch worin der Fehler liegt. Sobald ich eine
error.log habe, werde ich das prüfen.
Matthias schrieb:> Habe ich probiert, unverändertes Ergebnis.
Dann bricht Dein Script bei dem t_file Teil ab und der Teil mit der
Ausgabe wird nicht mehr ausgeführt. Wahscheinlich stimmt der Pfad nicht
bzw. es gibt kein Schreibrecht.
Setze mal folgenden Code an den Anfang des Scriptes:
Error in sys.excepthook: Traceback (most recent call last): File "/usr/lib/python3.4/cgitb.py", line 268, in __call__ self.handle((etype, evalue, etb)) File "/usr/lib/python3.4/cgitb.py", line 288, in handle self.file.write(doc + '\n') UnicodeEncodeError: 'ascii' codec can't encode character '\xfc' in position 1265: ordinal not in range(128) Original exception was: Traceback (most recent call last): File "/../cgi-bin/mycgi.py", line 27, in UnicodeEncodeError: 'ascii' codec can't encode character '\xfc' in position 22: ordinal not in range(128)
Lokal funktioniert es mit der open() Ergänzung um den utf-8 encoding
Zusatz. Damit war das Thema gegessen, dachte ich eigentlich.
Der Fehlermeldung nach liegt der Fehler im HTMLPart, der einen Umlaut
verwendet ((ü)bertragen).
Da das submitten der eigentlichen Formulardaten an das CGISkript auch
mit unicode funktioniert, habe ich einfach die Umlaute aus dem HTMLPart
genommen und ES LÄUFT!!