Stimmt schon. Kommt aber drauf an, was man tut.

Zitat:
HTTP-Nachrichten können einen Rumpf beliebiger Länge enthalten, so daß ein Mechanismus definiert werden muß, um das Ende einer Nachricht zu bestimmmen. HTTP/1.0 stellt dafür den Content-Length Header zur Verfügung, der die Länge des Nachrichtenrumpfes enthält. Dazu muß aber offensichtlich die Länge der Entität bereits im voraus bekannt sein, was bei dynamisch generierten Entitäten nicht der Fall ist. Bisher mußten solche Entitäten vollständig generiert und gepuffert werden, um ihre Länge zu berechnen und konnten erst dann verschickt werden, wodurch die Antwortzeit (bei großen Antworten deutlich) anwächst. Bei HTTP/1.0 ist dies noch kein bedenkliches Problem gewesen, da der Content-Length Header nicht notwendig gewesen ist, das Ende der Nachricht ist ja durch das Schließen der Verbindung markiert worden. In HTTP/1.1 ist dies nicht mehr sinnvoll, daher ist eine bessere Möglichkeit entwickelt worden, die fragmentierte Transferkodierung (Chunked Transfer-Encoding):
Der Sender zerlegt die Nachricht in Fragmente beliebiger Länge, die mit ihrer Länge verschickt werden, wobei ein leeres Fragment das Ende der Nachricht bezeichnet. Der Sender markiert eine fragmentierte Nachricht durch den Header Transfer-Encoding: chunked.
Dadurch kann der Sender jeweils nur kleine Teile der Nachricht puffern, ohne daß merklich Komplexität oder Overhead hinzugefügt wird. Aufgrund der Einfachheit dieser Lösung müssen alle HTTP/1.1-Implementationen dieses Verfahren unterstützen.

In deinem Fall - das Bild - ist schon okay, da du ja weißt, wie groß es ist.