[c++] Dateidownload liefert zu große Dateien!

[Extinction]

Hallo!
Ich habe mir ein kleines Downloadprogramm unter Windows geschrieben. Es läd soweit so gut auch die Dateien runter, aber nicht korrekt. Etwa jede 100'te Adresse (laut XVI32) ist eine Hexadezimalzahl zu viel in meiner Datei. Datendateien werden dadurch natürlich unbrauchbar. :/
Mein GET-String sieht so aus:

GET //sprache/trennen/bilder/test.gif HTTP/1.0

From: Testclient@test.de

User-Agent: Testtool/1.0

Host: www.prepolino.ch

Die Downloadschleife sieht wie folgt aus:

double c; bool ok=false;
        ofstream out;
        out.open(target.c_str());
        while ((bytesReceived = (sockdl.recv(Buffer, RCVBUFSIZE))) != 0)
        {
            for (int i=0; i<bytesReceived; i++)
            {
                if (ok) out << Buffer[i];
                if (i>3 && Buffer[i-3]=='\015' && Buffer[i-2]=='\012'
                        && Buffer[i-1]=='\015' && Buffer[i]     =='\012') ok=true;
                c++;
            }
        }
        out.close();
        if (verbose_level>=3)cout << "Downloaded " << (c/1024)/1024 << "MB successfully!\n";

Irgendwo dort muss der Wurm liegen. Denn selbst wenn ich den Buffer auf >1MB einstelle, die while Schleife also nur einmal durchläuft, bekomme ich zu viele Daten.:/

Edit: Habe die fiktiven Daten im GET Request durch die Passenden zum meinem nächsten Post ersetzt.

 

[CDW]

RECV kann nicht nur 0 zurückgeben, sondern auch -1 (im Fehlerfall)

Edit: könntest Du vielleicht ein Beispiel posten (Originaldatei und eine "falsch" übertragene) ?

 

[GrafZahl]

wäre es http 1.1 würde ich mal auf chunked transfer-coding orakeln, aber bei 1.0? ...

kannst du mal bitte den antwort header posten?

 

[Extinction]

@CDW
Ähm, ja, das ist bislang noch nicht berücksichtigt. ^^
Aber ich glaube eher nicht, dass es daran liegt, weil ich den Receive Buffer einfach so groß gewählt habe, dass bei einem Mal alle Daten ankommen. Die überzähligen Bytes sind aber mittend im Buffer.
Beispiel ist im Anhang als *.zip. Habo konvertiert scheinbar automatisch nach *.jpg, waren aber *.gif's. Habe jetzt außerdem ein paar andere Server probiert, das mit 100'te Adresse kommt nicht mehr ganz hin, siehe Anhang.

@GrafZahl
Hmmm... Hast vieleicht Recht. Wieso schickt der Server mir denn HTTP 1.1 zurück, wenn ich 1.0 requeste?
Hier der Header:

HTTP/1.1 200 OK

Date: Sun, 21 Nov 2010 10:19:16 GMT

Server: Apache/2.2.3 (Debian) mod_ssl/2.2.3 OpenSSL/0.9.8c

Last-Modified: Wed, 31 Dec 2003 16:08:43 GMT

ETag: "585196-5810-f3edf8c0"

Accept-Ranges: bytes

Content-Length: 22544

Connection: close

Content-Type: image/gif

Werd mich dann mal bzgl. chunked transfer-coding schlau machen.
Edit: Es fehlt aber das "Transfer-Encoding: chunked" im Header. Also ist es scheinbar nicht chunked. :/

 

[GrafZahl]

*g* hätte mir eigentlich schon beim lesen des quelltextes auffallen müssen ...

ofstream behandelt dateien per default als textdateien ...
probier mal folgendes:

out.open(target.c_str());

wird zu

out.open(target.c_str(), ios_base::out | ios_base::binary);

 

[CDW]

Jep. GrafZahl hat recht.
Die Testdaten haben "interessante" Unterschiede - alle 0xA des Originals sind durch 0xD, 0xA ersetzt worden (also "\n" durch "\r \n" )
Original:

00000040: 8de7 face f7fe 0f0c 0a87 c4a2 f188 4c2a

nach der Übertragung:

00000040: 8de7 face f7fe 0f0c 0d0a 87c4 a2f1 884c

Und das ist bei binären Daten nun mal fatal :wink:

Ersetze ich die "0d 0a" durch "0a", erhalte ich wieder ein "anzeigbares" GIF Bild :wink:

 

[Extinction]

Ouch, das hätte ich wissen müssen. >.<
Afaik passiert das unter Linux aber nicht.

Jedenfalls funktioniert es jetzt, danke.