Michael Heydekamp ([EMAIL PROTECTED]) schrieb am 02.07.04:

> 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<----------

Die Stelle ist mir beim Lesen von UUZ_TEST.TXT auch aufgefallen.

> 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:

[...]

> 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 pl�diere f�r 1:1 durchreichen, zumal in echten Binarys 0A oder 0D
durchaus vorkommen.

> 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.

Ach du Sch...

> 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...

Mir war ja klar, dass dieser Bug Arbeit f�r Dich bedeutet, aber wenn ich
geahnt h�tte, *was* ich da lostrete, h�tte ich wohl eher geschwiegen und
weiterhin die (wenigen) Rfc-Mails bearbeitet... ;-)

Gruss

Alex

------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list

Antwort per Email an