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?
Perfekt dann haben wir den Fehler für den TO gefunden: 'File does not exist: home...'
>Fehler in Zeile 42?? Wo siehst Du eine Zeile 42? >'File does not exist: home...' Wie kommst Du darauf?
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.
@DPA Habe mich bei dem \n\n nur an der Anleitung auf selfhtml orientiert. Werde es nachher mal ausprobieren, Danke.
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."
Ich hatte es mal mit \n\n probiert und das funktionierte bei meinen Browsern (Chrome, Firefox) nicht. Mit \r\n\r\n geht es aber.
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.
Hugo schrieb: > und was sagen die Log's und steht etwas in den Log's ? Die Antwort fehlt immernoch !
print("Content-type: text/html\r\n\r\n") macht das gleiche wie mein
ursprünglicher Header \n\n. Sry, habe mich gerade vertan. But
Python3Part yes, HTMLPart no.
Wie genau sieht denn der komplette Output wirklich aus, den dein Script erzeugt?
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.
Dirk B. schrieb:
>Evtl stört das letzte \n
Habe ich probiert, unverändertes Ergebnis.
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:
1 | import sys |
2 | sys.stderr = sys.stdout |
Das gibt eventuelle Fehler über den Browser aus.
THX Mario Hier die Ausgabe
1 | 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) |
Ahhhhhh Unicode-Verhackstückung!
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!!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.