Joachim Merkel <[EMAIL PROTECTED]> wrote on 03.07.04:
> Michael Heydekamp ([EMAIL PROTECTED]) schrieb:
[...]
>>>> in diesem Punkt den vorherigen Zustand als Temp-Fix erstmal wieder
>>>> herzustellen - dazu bitte Meinungen.
>>> Ja, TYP: BIN ist was anderes als Transfer-encoding-binary.
>> Abgesehen davon, dass "TYP: BIN" IMO exakt CTE binary entspricht:
>> Was heisst das "Ja"? Alten Zustand wiederherstellen?
> Deine Frage war doch "den alten Zustand wieder hergestellen" und ich
> schreibe ja. Also nochmal ja.
Deine Erg�nzung "TYP: BIN ist was anderes als Transfer-encoding-binary"
hinterlie� bei mir den Eindruck, als w�rdest Du das sogar als
eigentliche und "echte" L�sung ansehen (und nicht nur als Temp-Fix).
Das konnte ich mir nicht recht vorstellen, deshalb hatte ich
sicherheitshalber nochmal nachgefragt.
Denn "alten Zustand wiederherstellen" hie�e ja auch, qp-codierte
Bin�rdaten nicht decodieren zu k�nnen, deshalb k�me das f�r mich
wirklich nur als Temp-Fix in Frage. Er wird IMO aber gar nicht n�tig
sein.
Wobei sich, je l�nger ich dar�ber nachdenke, eine Reihe von Fragen
ergeben, die ich erst mal kl�ren mu�.
Derzeit neige ich dazu, bei Multiparts ein "outer labelling" im CTE-
Header g�nzlich zu ignorieren. Nicht nur, um das von Alex vorgebrachte
Problem zu l�sen, sondern auch, weil Multiparts mit �u�erem CTE binary
schon seit jeher als "B" (statt als "M") in XP geflagged werden.
Alleine das ist ja auch schon falsch - Multipart ist Multipart.
Das Ignorieren des �u�eren CTE-Headers w�rde au�erdem das Problem mit
den derzeit fehlenden CRLFs bereits l�sen, aber da ist noch zu pr�fen,
ob es z.B. Multiparts geben kann (bzw. ob sie standardkonform w�ren),
deren kompletter Body base64-codiert ist (inkl. der Boundaries und
allem, was zu einer Multipart geh�rt). So da� die einzelnen Teile erst
nach einer b64-Decodierung zum Vorschein k�men... In diesem Fall k�nnte
man den Header nicht einfach ignorieren.
Des weiteren mu� ich pr�fen, ob der das Problem verursachende Fix
�berhaupt und wirklich OK ist. Bei base64-Binaries ist klar, wie die
Daten decodiert werden m�ssen, bei qp-Binaries bin ich jetzt gar nicht
(mehr) sicher, wie *uncodierte* Zeilenumbr�che behandelt werden m��ten.
Theoretisch m��ten die Zeilen bei qp-Binaries durchgehend mit soft line
breaks versehen sein, aber das wird sich durch nochmalige RFC-Lekt�re
hoffentlich kl�ren lassen.
Ob und wie Singleparts in punkto Auswertung des CTE-Headers anders zu
behandeln sind als Multiparts, ist ein weiterer Punkt.
Dazu werde ich was in c.f.dev schreiben, sobald mir diese Dinge klar
sind.
> Wenn ZConnect voll bin�rf�hig ist, weil es bytecount - also
> einen LEN:-Header hat, dann ist es bei RFC eben noch nicht so.
Schau mal in die einzelnen Teile der von Alex geschickten Nachricht. Da
sehe ich z.B. "Content-Length: 1832" (obwohl diese gar nicht als binary
deklariert sind).
Aber das nur nebenbei, f�r die o.g. offenen Fragen ist das irrelevant.
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
