Michael Heydekamp <[EMAIL PROTECTED]> wrote on 01.07.04:
> Wodurch verursacht, wei� ich noch nicht genau, aber ich habe
> zumindest einen Verdacht in eine bestimmte Richtung (Seiteneffekt
> eines Fixes f�r einen bisherigen Bug).
Scheint nach ersten Beobachtungen zu stimmen, und zwar dieses Fixes:
----------8<----------
8. Daher wird bei qp-codierten Nachrichten jetzt nur noch dann ein
Zeilenumbruch (CRLF) an decodierte Zeilen angeh�ngt, wenn es sich
nicht um eine Bin�rnachricht handelt. Diese Ma�nahme in Verbindung
mit Punkt 7. stellt sicher, da� jetzt auch qp-codierte Bin�rnach-
richten korrekt decodiert w�rden - was bisher schlicht unm�glich
gewesen w�re.
----------8<----------
Dieser Fix wirkt sich aber auch auf Bin�rnachrichten generell aus (ob
qp-codiert oder nicht), und wenn man das zu Ende denkt und ich nichts
�bersehe, ist der obige Fix OK, legt nun aber einen schon immer
bestehenden Bug im UUZ offen, der bisher nur kaschiert wurde und deshalb
nicht aufgefallen ist, weil Nachrichten mit echten, uncodierten
Bin�rdaten extrem selten sind:
Bisher wurde jedes EOL (end of line) wie ein LF beim Lesen zun�chst
entfernt und anschlie�end durch das bei ZConnect-Textnachrichten
obligatorische CRLF ersetzt - und zwar auch bei uncodierten
Bin�rnachrichten!
D.h., auch bisher schon w�ren uncodierte Bin�rdaten (sofern sie LFs
enthalten) schlicht ver�ndert und damit zerst�rt worden. Dieses
Resultat kann ich mit allen mir zur Verf�gung stehenden UUZ-Versionen
aller XP-Derivate verifizieren, mindestens bis runter zur v3.12d und
einschlie�lich des UUZ von OpenXP.
Durch den obigen Fix werden jetzt eben keine CRLFs mehr angeh�ngt, und
das f�hrt nach dem Entfernen des EOL zu dem Effekt, da� sie bei dieser
Nachricht dann schlu�endlich ganz fehlen.
Der jetzt notwendige Fix w�re also nicht, den obigen Fix wieder
r�ckg�ngig zu machen, sondern konsequenterweise bei als "binary"
deklarierten Nachrichten ein EOL erst gar nicht zu entfernen - sondern
1:1 im Originalzustand zu belassen. Man k�nnte h�chstens daran denken,
in diesem Punkt den vorherigen Zustand als Temp-Fix erstmal wieder
herzustellen - dazu bitte Meinungen.
Ich mu� das nochmal durch Nachdenken, Testen und RFC-Lekt�re endg�ltig
verifizieren, aber so stellt sich mir das im Moment dar. Und wenn der
Gedankengang richtig sein sollte, dann wird das spannend und recht
aufwendig, denn dann ist die seit jeher benutzte Leseroutine
'readstring' f�r solche Nachrichten im momentanen Zustand komplett
untauglich - und zwar schon seit anno dickemilch.
Und ganz dramatisch w�rde es werden, wenn nicht im "outer labelling",
sondern in einem der inneren Nachrichtenteile als CTE "binary"
deklariert ist - das w�rde n�mlich hei�en, da� der UUZ komplett die
einzelnen Teile der MIME-Nachricht parsen m��te, was er sich bisher
schlicht geschenkt und XP �berlassen hat.
Ich hoffe, da� ich da noch einen Denkfehler habe und mir *das* sparen
kann, denn das kann dann dauern...
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
