([EMAIL PROTECTED]) schreibt:
>> * Ebenso wichtig ist es, bei zu gro�en L�ngenangaben zumindest in
>> dem betreffenden Abschnitt alle LEN: 0 zu setzen, weil der ZPR
>> keine �berl�ngen �ber mehrere Nachrichten erkennen kann.
> Verstehe ich das richtig? ZPR akzeptiert nur eine �berl�nge, die
> nicht weiter reicht als die Gr��e der im Puffer jeweils
> darauffolgenden Nachricht? Wei�t Du, wie ZPR dabei prinzipiell
> vorgeht?
Der ZPR untersucht bei als fehlerhaft erkannten L�nge nur die
Grenzbereiche der Nachrichten. �berdeckt eine falsche zu gro�e
L�ngenangabe mehrere Nachrichten, w�rden nur Unklarheiten
beim Header der Folgenachricht (oder das das Fileende)
u.U. die falsche (�berl�nge) etwas verk�rzen (oder ggf. auch
verl�ngern).
> Andere Frage: Wie erkennt ZPR Unterl�ngen, anhand welcher Kriterien
> und Merkmale wird eine Nachricht auf welche L�nge gek�rzt? (Mich
> besch�ftigen diese Fragen vor allem, weil auch mein Programm HeaDel
> mit falschen Angaben im LEN-Feld in gewissem Umfang korrigierend
> umgeht.)
Die Pflichtheader und nur die bestimmen f�r den ZPR den Header.
Er erkennt auch weitere 17 Headernamen und ignoriert alle anderen,
von denen der ZPT annimmt, da� es Headernamen sind.
Im Quellcode stehen diese (s.u.), wobei der Mechanismus
beim ZPR nicht so einfach durchschaubar ist.
Zuerst wird in einer Routine alle eingelesenen Zeilen
mit Headernamen mit einer gespeicherten Liste verglichen, solange
bis ein kompletter Header erkannt wird. Passiert das nicht,
wird eben u.U. der gesamte Puffer als headerlos zur L�schung
vorgeschlagen.
(Au�er den f�r als notwendig erachteten Content-Checks, werden
die meisten der anderen Headernamen nur in besonderen F�llen
(bei Schalter -h) �berhaupt genauer gepr�ft (ansonst wird wohl
bei Schalter -h immer auch noch die Schreibweise aller bekannten
Headernamen gecheckt). Weitere f�nf Ausnahmen (s.u.)werden ebenfalls
immer gepr�ft.)
Da die LEN:-Angabe bekannt ist, wird ab der bekannten L�nge
auf den n�chsten Header von ZPR �berpr�ft.
Wird der n�chste Header bei der Suche ab der Position der
gemerkten L�nge problemlos gefunden, wird LEN: akzeptiert.
Ist das nicht problemlos, wird dann aber noch r�ckw�rts gesucht,
bis eine Zeile kein ":" als Trennzeichen enth�lt und damit definitiv
auch nicht mehr ein - auch ein nicht ausgewerteter - Headername
sein kann.
Diese R�ckw�rtssuche kann dann auch zur Verk�rzung einer
vorhergehenden Nachricht f�hren.
(Ich hoffe ich habe das einigerma�en zutreffend beschrieben,
in alle Details habe ich das nicht versucht zu verstehen.)
Ein Fall wurde ja von mir schon in der dev-Gruppe genannt, wenn
eine Nachricht mit LEN: 0 versehen und danach korrigiert wird,
die am Ende in der vorletzten Zeile ein Web: etc. und in der
letzten ein FTP: stehen hatte, wurde diese der folgenden
Nachricht (ebenfalls mit LEN: 0) zugeschlagen und der Anfang dieser
Nachricht dann bereits auf den als EB: erkannten Teil von Web:
festgelegt.
(Diese "Headerzeile" wurde dann sinnigerweise gel�scht, weil
EB: nicht in AMs vorkommen d�rfen, damit war die letzte Zeile dann
WFTP: etc., die dann als Headeranfang erkannt wurde.)
Wenn also die sieben Pflichtheader drin sind, wird der Header als
g�ltig akzeptiert. Das Problem ist das Setzen des korrekten Anfangs.
Wenn ich ein leeren EMP: an den Anfang des Headers setze, bedeutet
das auch nicht in jedem Fall, das nur Pflichtheader den Anfang
markieren, aber auch nicht jeder ZPR bekannte Headername.
Ich habe nicht hinbekommen, z.B. die typische erste Zeile U-Received:
testweise erkennen zu lassen. ZPR erkennt immer erst die dritte
U-Received als Headeranfang.
In jedem Fall wird aber mit leerem EMP: keine Zeile danach als
Headeranfang gew�hlt.
Man mu� eben auf die Warnungen beim Testlauf achten und sie
interpretieren k�nnnen. Aber insgesamt ist das von mir vorgeschlagene
Verfahren sehr robust, um falsche L�ngen zu korrigieren.
Es gibt nur 4 Header die nicht in AM resp. PM vorkommen d�rfen
(aus ZPR-Sicht - s.u.), das sind EB:, PRIO und CRYPT bei AMs und
DISKUSSION-IN: bei PMs.
An diesen Abl�ufen bei der L�ngenerkennnung wird vermutlich
niemand mehr wirklich weiterreichende �nderungen vornehmen wollen.
Alle beschriebenen Vorg�nge spielen sich in einer Routine Checkrepair
ab, die schon einiges Lehrreiches enth�lt.
Was anderes ist die Problematik der Zeilendenzeichen:
Ein einfaches CR (Ascii#13) oder ein einsames LF (Ascii#10) in
einer Headerzeile machen den kompletten Header defekt und ZPR
w�rde die gesamte Nachricht als headerlos l�schen wollen.
Aus einem Robustness-Prinzip werden aber solche Header in XP
eingelesen.
Das Zeilenende ist bekanntlich CRLF und nur das interessiert XP.
Man sollte daher die entsprechende Routine in ZPR ebenso robust
machen und demzufolge eine alleinige und eindeutige Identifizierung
von Zeilenenden durch CRLF statt der zus�tzlich bisher korrigierten
einzelnen CR und LF.
--------------------------------zip-----------------------------------
{ Liste aller Headerzeilen, die in irgendeiner Form �berpr�ft werden.}
{ Alle �brigen Zeilen werden nicht interpretiert. }
headerindex : array[1..knownheaders] of
record
name : string[15];
multi : boolean; { Zeile darf mehrfach vorkommen}
ampm : byte; { 1=PM, 2=AM, 3=beides }
end =
((name: 'ABS'; multi: false; ampm: 3),
(name: 'ANTWORT-AN'; multi: true; ampm: 3),
(name: 'BET'; multi: false; ampm: 3),
(name: 'BEZ'; multi: true; ampm: 3),
(name: 'CRYPT'; multi: false; ampm: 1),
(name: 'DDA'; multi: false; ampm: 3),
(name: 'DISKUSSION-IN'; multi: true; ampm: 2),
(name: 'EB'; multi: true; ampm: 1),
(name: 'EDA'; multi: false; ampm: 3),
(name: 'EMP'; multi: true; ampm: 3),
(name: 'FILE'; multi: false; ampm: 3),
(name: 'LEN'; multi: false; ampm: 3),
(name: 'MID'; multi: false; ampm: 3),
(name: 'O-EDA'; multi: false; ampm: 3),
(name: 'OAB'; multi: false; ampm: 3),
(name: 'PRIO'; multi: false; ampm: 3),
(name: 'ROT'; multi: false; ampm: 3),
(name: 'TELEFON'; multi: false; ampm: 3),
(name: 'TRACE'; multi: false; ampm: 1),
(name: 'WAB'; multi: false; ampm: 3),
(name: 'OEM'; multi: true; ampm: 3),
(name: 'KOM'; multi: false; ampm: 3),
(name: 'KOP'; multi: true; ampm: 3),
(name: 'VER'; multi: true; ampm: 3));
[Die Bezeichner dienen content-checks]
hdf_ABS = 1; hdf_EB = 8; hdf_OAB = 15;
hdf_ANTWORT = 2; hdf_EDA = 9; hdf_PRIO = 16;
hdf_BET = 3; hdf_EMP = 10; hdf_ROT = 17;
{ hdf_BEZ = 4;} hdf_FILE = 11; hdf_TELEFON = 18;
hdf_CRYPT = 5; hdf_LEN = 12;
hdf_DDA = 6; hdf_MID = 13; hdf_WAB = 20;
hdf_DISK = 7; hdf_OEDA = 14; hdf_OEM = 21;
hdf_KOM = 22;
hdf_KOP = 23;
hdf_VER = 24;
[Das sind Pflichtheader]
stdhdindex : array[1..stdhdlines] of byte =
(hdf_LEN, hdf_ABS, hdf_BET, hdf_EDA,
hdf_EMP, hdf_MID, hdf_ROT);
--------------------------------zap-----------------------------------
--
Salut
_)oachim
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
