Hans-Juergen Taenzer <[EMAIL PROTECTED]> wrote on 06.04.05:
> Michael Heydekamp ([EMAIL PROTECTED]) wrote:
>> M��te, ja. Kann im Newsbatch auf Anhieb auch keinen Grund sehen,
>> was die Ursache sein k�nnte, warum er das nicht tut. Hab'
>> allerdings auch noch nicht gepr�ft, ob die L�nge in der
>> rnews-Zeile korrekt ist. Ist sie?
> Nachdem das nicht durch einfaches Abz�hlen festzustellen ist, hab'
> ich ein kleines �berpr�fungs-Programm geschrieben. Die "#! rnews"
> Eintragungen sind alle korrekt. 0x0d 0x0a Kombinationen kommen
> �brigens nicht vor (Z�hlproblemtik).
Die w�rde der UUZ aber ohnehin korrekt abfangen (vorausgesetzt, der
Newsbatch ist RFC-konform).
>> Konnte das Problem jedenfalls insofern eingrenzen, als da� eine
>> Konvertierung *nur* der betreffenden Nachricht einen korrekten
>> LEN:-Header produziert. Mu� also offenbar mit einer der
>> vorherigen Nachrichten zu tun haben, und insofern ist nicht
>> auszuschlie�en, da� davon eine defekt ist und/oder einen falschen
>> rnews-Header hat.
> Das Merkw�rdige ist, da� man scheinbar *keine* Nachricht vor der
> fehlerhaft konvertierten l�schen kann, ohne da� der Fehler
> verschwindet.
Aber wenn man *alle* Nachrichten davor entfernt, dann klappt es. H�?
Zwischenzeitlich hatte ich ganz stark diese UTF-8-Nachricht *nach* dem
betreffenden Posting im Verdacht (h�tte durchaus sein k�nnen, weil jeder
Newsbatch zweimal durchlaufen wird -- beim ersten wird die L�nge f�r den
LEN:-Header ermittelt, beim zweiten wird konvertiert).
Aber wenn man nur diese UTF-8-Nachricht entfernt, wird immer noch ein
falscher LEN:-Header erzeugt.
>> Problem ist notiert, Geduld bitte. Ist insofern nicht arg
>> kritisch, als da� XP den Puffer ohne Murren einliest (dabei aber
>> das letzte 0A schlabbert).
> Mhm. Zumindest XPFilter und (verst�rkt) XPBMF reagieren allergisch
> auf den falschen LEN-Header.
Ich wei�...
>> Und interessant w�re auch zu wissen, ob es �berhaupt einen UUZ
>> gibt, bei dem dieses Problem nicht auftritt (und welcher das ist).
> Damit kann ich dienen. Der aktuelle UUZ von Eurer Webseite hat das
> Problem mit *diesem* Newsbatch nicht (Zeitstempel: 30.08.2003 00:00,
> Gr��e: 152.928).
Das ist aber doch genau der UUZ, der bei dem seinerzeit ebenfalls nicht
RFC-konformen Newsbatch (ISO-8859-1 als UTF-8 deklariert) einen ganz
�hnlichen Fehler produziert hatte.
Die Behebung dieses Problems schafft eines bei dem nun in Rede stehenden
Newsbatch? Hmm...
> Aber wie schon fr�her geschrieben, habe ich hier einen Newsbatch, mit
> dem dieser UUZ nicht zurechtkommt.
Ich nehme mal an den, um den es schon damals ging und der Anla� f�r die
umfassenden Fixes f�r f�lschlicherweise als UTF-8 deklarierte ISO-Header
war?
>> Habe mal wahllos einen beliebigen UUZ von XP2 vom 07.09.2001
>> herausgegriffen, der l�uft gleich v�llig Amok: Die betreffende
>> Nachricht ist gleich dreimal im ZC-Puffer enthalten (allerdings
>> mit korrekter L�nge), daf�r fehlen andere Nachrichten offenbar
>> gleich ganz, wie ich aus der Gesamtgr��e der Zieldatei schlie�e
>> (die ist kleiner als die vom FreeXP-UUZ erzeugte).
>> Was den Verdacht n�hrt, da� wir es hier mit einem massiv defekten
>> Newsbatch zu tun haben, mit dem der FreeXP-UUZ sogar noch
>> vergleichsweise gut klarkommt...
> Zumindest technisch scheint der Batch in Ordnung zu sein, wenn man
> mal davon absieht, da� enorm lange Headerzeilen vorhanden sind.
Das ist ja kein Verbrechen und zul�ssig.
> Die laengste Zeile hat 429 Bytes (Path:).
Kein Thema.
> Auch die "Korrektur" des seltsamen Datumseintrags "Date: 20 Feb 2005
> 15:47:42 -0600" bringt keine �nderung.
Was ist daran seltsam?
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[email protected]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
