nicht angemeldet
genauso haben wir und da schon einmal rangehangelt. Dann sagte einer 2822 (und nicht JEHOVA) und ein Posting ergab das andere.
Ja, für 7-bit-US-ASCII-Text-Messages mag das gelten (gegolten haben). HTTP-Bodys sind aber nun mal ausdrücklich *OCTET und _nicht_ US-ASCII und auch nicht 8-bit-Text.
Zeilenumbruch:
Die MIME-Spezifikation RFC 2046 4.1 verlangt von text/*-Typen CRLF als Zeilenumbruch. Dies ist im Speziellen auch noch in RFC 2854 für text/html angegeben, allerdings gleich mit dem Hinweis auf eine Ausnahmeregelung, die bei HTTP in RFC 2616 3.7.1 angegeben ist: "HTTP relaxes this requirement and allows the transport of text media with plain CR or LF alone representing a line break".
Unterm Strich ist es also egal. Niemand wird ernsthaft einen Unterschied zwischen per HTTP empfangenen und zum Beispiel von der Festplatte gelesenen HTML-Dateien machen, zumal HTML selbst kein Zeilenendformat definiert. Die ganze Geschichte musste wohl in gewisser Hinsicht zwangsweise wegen MIME hintenrum auf HTML aufgeladen werden.
Zeilenlänge:
Die Zeilenlänge ist für text/, für text/html, für HTML und erst recht nicht für HTTP festgelegt. Gerade bei HTTP wäre so etwas kontraproduktiv, wie sollten sonst Binärdateien (bekanntermaßen ohne Kodierungen wie base64 oder uu) transportiert werden.
Die Begrenzung auf 998 Zeichen + CRLF gibt es nur für Nachrichten im Internet Message Format (Hauptanwendung: email) gemäß RFC 2822. HTTP bezieht sich auf den Vorgänger von RFC 2822, RFC 822, dort allerdings ausschließlich auf Abschnitt 3.1, der sich lediglich allgemein mit dem Nachrichtenkopf befasst, nicht mit dem Nachrichtenkörper, um den es bei HTML gehen müsste. Und obwohl man RFC 822 als durch RFC 2822 ersetzt ansehen kann, wäre kurioserweise anzumerken, dass in RFC 822 generell überhaupt keine Rede von einer begrenzten Zeilenlänge ist (nur eine Empfehlung von 72 Zeichen zur besseren Lesbarkeit)
So, und nun möge man mir das Gegenteil mit Textnachweisen darlegen, ein "ich habe mal gehört" reicht mir nicht.