Hallo, ich habe in dieser Mailingliste und in Newsgroups von PDF-Problemen gelesen, die mich zur Zeit auch quälen. Ich habe aber keine Lösung gesehen. Vielleicht habe ich aber einen Ansatz... Kurz und knapp gesagt, ist das Problem auch äußerst verwirrend. Mein C++-Testprogramm (cgi) funktioniert, wenn keine POST-Nachricht gesandt wurde. Ich habe das ganze auf dem Squid protokolliert. Dabei habe ich folgende Beobachtungen gemacht: 1) Nach einer GET-Anforderung vom Browser kommt eine Antwort vom     Server mit der PDF-Datei. Anschließend schickt der Browser die     gleiche Anfrage noch einmal und erhält noch einmal das File. 2) Wenn eine POST-Nachricht vom Browser an den Server gesandt wird,     bekommt der Browser eine OK-Meldung zurück, inclusive PDF-File     (weil hier die PDF-Generierung zur Antwort gehört). Sofort darauf     schickt der Browser eine GET-Nachricht mit der gleichen URL, wie      sie im action-Attribut des FORM-Tags angegeben war. Hierbei werden     jedoch keine Formulardaten übertragen. Deshalb schickte mein     CGI-Script auch nur eine normale HTML-Antwort. Ich habe hin und her probiert. Im Ergebnis muß ich auf die POST-Nachricht mit einem "Content-type: application/pdf" reagieren, aber darf die PDF-Datei nicht mitschicken. Auf die anschließende GET-Anforderung hin schicke ich erst die PDF-Datei. Das funktioniert mit allen Browsern, aber irritiert mich: ist das richtig so, muß das so sein? Ist das zuverlässig? Wie macht man das, damit man ohne SESSION und ohne COOKIE die zweite GET-Anforderung richtig zuordnen kann und das File sendet? Zu Punkt 2): jetzt läuft es bei mir so ab: Mein CGI-Programm bekommt vom Browser eine POST-Anfrage. Das PDF wird generiert und folgender http-Header wird zum Client gesendet:         Content-Type: application/pdf; filename=rechnung.pdf         Content-length: 0         Set-Cookie:RECHNSESSID=2687f474b7937fa1b2d26d4a8bb7e11d;                  Comment=SessionID; Domain=.comparat.intra;                  Max-Age=3600; Path=/; Version=1 In der Datenbank speichere ich zur Session den generierten PDF-Filename. Beim direkt darauf folgenden GET vom Client mit der passenden Session-ID sende ich den folgenden Header und den Inhalt des PDF-Files zurück:         Content-Type: application/pdf; filename=rechnung.pdf         Content-length: 70558 (( das "filename=rechnung.pdf" ist vielleicht nicht nötig. Probiere ich auch nochmal)) Ist das professionell oder stümperhaft? Wie macht ihr das? Um es klar zu machen: Tom hat am 12.3. in dieser Liste das gleiche Problem geschildert. Mein CGI-Programm soll euch nicht darüber hinweg täuschen, dass es sich um ein generelles Problem zwischen SuSE 9 und Apache 2 zu handeln scheint. Ich habe auch einen RedHat-Server mit Apache 2 und auf diesem funktioniert die Anzeige von PDF einwandfrei auch mit dem IE 5.5. Ich habe mein SuSE 9 / Apache2 System getestet, auf der einfachsten Ebene. Der Standard-Konfiguration von SuSE habe ich nur nachgeholfen, indem ich in / etc/sysconfig/apache2 der Variablen APACHE_MODULES das Modul "mime_magic" hinzugefügt habe. Das hat aber am Problem nichts geändert. Ein simples Stück HTML mit " <a href="/rechnung.pdf">Rechnung</a> " und mit "<a href="/beispiel.txt">Beispiel</a>" sei gegeben. Die beiden Dateien stehen im Document-Root. Klickt man auf einen Link, bekommt man die Datei zu sehen, zumindest mit dem Konqueror. Als freundlicher Mensch schaue ich noch, ob das auch unter MS funktioniert - und siehe da: der IE 5.5 (andere Versionen nicht getestet) kann nur "Beispiel" laden, bei Rechnung wird nur eine leere Seite angezeigt (keine Fehlermeldung, keine Frage, ob Plugins ausgeführt werden sollen). Natürlich kann ich ganz normal PDF-Dateien von überall laden / anklicken. Nur nicht von meinen Servern mit SuSE 9 und Apache 2 (2.0.48 und 2.0.47) und Squid (2.5.STABLE3). Kann nicht mal jemand mit tieferen Kenntnissen in diesem Bereich ermitteln, was da los ist? Die MIME-Geschichte habe ich geprüft, so gut ich kann. Das Apache-Modul "mime_magic" habe ich noch explizit dazugeladen, weil es in der Standard-Installation von SuSE nicht geladen war. Nochwas: der Squid ist nicht das Problem. Ich habe es auch ohne Squid getestet. Grüße an alle :-) Manfred -- COMPARAT Software-Entwicklungs-GmbH Mobile Voice Solutions Prießstr. 16, 23558 Lübeck Tel: 0451/479 56 60 Fax: 0451/479 56 62 http://www.comparat.de http://www.mobile-voice.de http://www.address-server.de http://www.adr3000.de