Ich versuchs kurz und bündig zu erklären.

Mein Programm baut eine HTTP Verbindung zu einem Webserver auf.

Dort geife ich mit "GET /img.php HTTP/1.1" auf eine Captcha zu.

Zurück bekomme ich dann den Inhalt des Bildes samt Headers, sprich derartiges wie zB. "Content-type: image/png".

Per ofstream will ich besagten Inhalt ganz einfach als verwendbare .png bzw. .bmp Datei abspeichern.

Leider funktioniert es weder wenn ich die Headers im Sourcecode drinlasse, noch wenn ich sie entferne und praktisch nur noch wirres Kryptisch speicher (was bei einem Bild ja nicht verkehrt ist).

Wie gesagt - es funktioniert leider nicht.

Muss ich den Sourcecode erst noch encrypten bzw. decrypten, oder was ist zu tun?

Lieben Gruß und schon mal Danke im Voraus,

paSe

Grüssli

Da wird dann halt beschrieben, was für eine Aufgabe welcher Header hat.

Den Großteil davon kann man wohl auch so nachvollziehen.

Das Manual mag interessant sein - keine Frage - nur wie es mir dabei helfen soll, nach der Headertrennung vom Sourcecode den Sourcecode nutzbar zu machen, verstehe ich nicht.

Ich danke Dir trotzdem!

Aber vielleicht wäre für dich eher sowas wie CURL von Interesse:
http://curl.haxx.se/libcurl/
bzw. der C++ Wrapper:
http://curl.haxx.se/libcurl/cplusplus/

Grüssli

Ich geh an die Sache mal anders ran ...

Response Headers:

HTTP/1.1 200 OK
Date: Fri, 13 Mar 2009 18:07:28 GMT
Server: Apache
X-Powered-By: PHP/5.2.1
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: image/png

Date, Server, X-Powered-By und Expires sind Header die wirklich nicht erklärt werden müssen!

Cache-Control händelt die Auslagerung.
Ebenso das no-cache Pragma.
Keep-Alive setzt die maximale Timeoutzeit bis die Verbindung unterbrochen wird.
Connection hat mit der Verbindungsaufrechthaltung zu tun - in diesem Fall bleibt sie offen bis das Timeout abläuft.
Transfer-Encoding sagt nur, dass der Server so lange Daten sendet bis das Ende erreicht ist und er deshalb noch kein genaue Content-Length geben kann.

Wenn man sich das jetzt mal ansieht, stellt man recht schnell fest, dass der einzige Header, der was mit der Kodierung zu tun haben kann Content-Type ist.
Hier wird jedoch auch nur festgelegt, welches Format der Sourcecode ist, undzwar PNG.

Genau an dem Punkt war ich aber bereits als ich diesen Thread eröffnet habe und ich sage dir ganz klar: Das ist ein Livecapture aus Wireshark.

Ich habe weder Headers vergessen noch welche hinzugefügt, sondern schlicht aus dem TCP Stream kopiert - mehr wird nicht gesendet.

Dass der Content erst nach dem doppelten Zeilenumbruch anfängt, ist mir übrigens auch bewusst - wie ich also die Headers vom Sourcecode trenne weiß ich.

Und genau damit komm ich jetzt wieder auf meine ursprüngliche Frage zurück, die im Grunde genommen nur heisst:

Muss man diesen Sourcecode, den Sourcecode des PNG Bildes, noch (de-)kodieren um den endgültigen Code zum Abspeichern des Bildes zu bekommen?
Denn ohne eine Bearbeitung des PNG Sourcecodes kann ich das Bild nicht öffnen - und Nein!, wie man ein PNG Bild (de-)kodiert steht bestimmt nicht in der HTTP Doku.

Uff, das las sich evtl. gerade etwas aggressiv - ich meine das um gottes Willen nicht böse, nur fühle ich mich zZ irgendwie missverstanden.

Lieben Gruß,

paSe

Uff, das las sich evtl. gerade etwas aggressiv - ich meine das um gottes Willen nicht böse, nur fühle ich mich zZ irgendwie missverstanden.

Aggressiv? Nein, aber ich werde gleich aggressiv
Wieso zum GEIER liest du nicht einfach dieses verdammte RFC durch, wenn du mit HTTP arbeiten willst. Du nimmst da einfach Dinge an, welche gar nicht stimmen! Bestes Beispiel:

unlimieD.paSe schrieb:

Transfer-Encoding sagt nur, dass der Server so lange Daten sendet bis das Ende erreicht ist und er deshalb noch kein genaue Content-Length geben kann.

Nein, eben nicht. Wenn du das RFC gelesen hättest, wüsstest du, dass dies unteranderem auch heisst, dass im Content selber noch Hex-Zahlen vorkommen, welche jeweils die Längen der Chunks angeben.

Hier kann man echt nichts mehr anderes sagen als: R T F M
Mit Übersetzung: http://de.wikipedia.org/wiki/RTFM#R

Wenn du zudem das RFC gelesen hättest, dann wüsstest du auch, dass der Content einfach nur Bytes sind, welche je nach dem kodiert sind. Wie ein PNG aufgebaut ist, ist dem HTTP völlig schnurz egal. Trotzdem kann es die Bytes kodieren. Aber eben, lies das RFC. Es steht alles dort drin!

Grüssli

PS: Die Aggression sollte man mit einem leichten bemitleidenswertem Lächeln verbinden