Neue UUZ-Testversion v3.40.1b (was: Content-Transfer-Encoding: binary)
Michael Heydekamp [EMAIL PROTECTED] wrote on 05.07.04: [...] Ich mache das auch deswegen so bewußt ausführlich, weil die bisherigen Routinen überwiegend geerbt sind, ich mich mit diesen Detailfragen erstmals näher beschäftige, demzufolge darin noch nicht 100% sattelfest bin und es für sinnvoll halte, wenn das nochmal gegengeprüft wird. [...] Da dazu zumindest kein Einspruch zu vernehmen war, gehe ich davon aus, daß sich alle sachkundigen Mitstreiter intensiv damit beschäftigt und alles für korrekt befunden haben? ;-) Frachjanur, weil ich vorhatte, morgen die neue Testversion hochzuladen, sobald ich noch einen Fix vorgenommen und die Doku komplettiert habe... Michael FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Content-Transfer-Encoding: binary
Michael Heydekamp ([EMAIL PROTECTED]) schrieb: Um die Konvertierung von text/html zu verhindern, wurde bisher nur auf den Subtyp geprüft (also */html). Die Frage ist, ob man das erstens so lassen (oder gezielt auf text/html prüfen) sollte und wie man zweitens dann mit text/enriched verfährt. kannst Du vermutlich genauso prüfen, damit auch genau verständlich da steht was ich meine: */enriched. (Ob das obsolete rich text in dem Zusammenhang noch eine Bedeutung hat, würde ich jedenfalls verneinen.) Soweit ich sehen kann, kann enriched nur zusammen mit text/ vorkommen, bei /html bin ich nicht sicher, kenne es aber aus der Praxis auch nur als text/html. RFC 1896 hattest Du ja schon erwähnt. Dem wäre eigentlich aus meiner Sicht nichts hinzuzufügen. Der Content-Type heißt txt/enriched. Zu text/html relativ ergiebig für einen Überblick ist: zip--- Network Working Group D. Connolly Request for Comments: 2854 World Wide Web Consortium (W3C) Obsoletes: 2070, 1980, 1942, 1867, 1866L. Masinter Category: Informational ATT June 2000 The 'text/html' Media Type Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. [...] 2. Registration of MIME media type text/html MIME media type name: text MIME subtype name: html Required parameters: none Optional parameters: [...] zap--- Darin findet sich auch ein Hinweis auf RFC 2557 Abschnitt 10, wo die Überschneidungen und zwischen HTTP und MIME bzgl. diese Media-Types etwas beleuchtet werden. zip--- Network Working Group J. Palme Request for Comments: 2557 Stockholm University/KTH Obsoletes: 2110 A. Hopmann Category: Standards Track Microsoft Corporation N. Shelness Lotus Development Corporation March 1999 [...] 10. Character encoding issues and end-of-line issues For the encoding of characters in HTML documents and other text documents into a MIME-compatible octet stream, the following mechanisms are relevant: [...] zap--- -- Salut _)oachim FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Content-Transfer-Encoding: binary
Joachim Merkel [EMAIL PROTECTED] wrote on 07.07.04:
Michael Heydekamp ([EMAIL PROTECTED]) schrieb:
Um die Konvertierung von text/html zu verhindern, wurde bisher nur
auf den Subtyp geprüft (also */html).
Die Frage ist, ob man das erstens so lassen (oder gezielt auf
text/html prüfen) sollte und wie man zweitens dann mit text/enriched
verfährt.
kannst Du vermutlich genauso prüfen, damit auch genau verständlich
da steht was ich meine: */enriched. (Ob das obsolete rich text
in dem Zusammenhang noch eine Bedeutung hat, würde ich jedenfalls
verneinen.)
Vermutlich nicht, aber die eine zusätzliche Prüfung frißt ja kein Brot.
BTW habe ich die ganzen Entscheidungen (Text vs. Binär, Charset-
Konvertierung ja/nein, Default-Charset setzen usw.), die bisher was weiß
ich wo verstreut waren und teilweise sogar mehrfach existierten, in der
schon bisher existierenden Routine 'MimeAuswerten' mal zentral
zusammengefaßt. Schafft einen besseren und einfacheren Überblick und
man sieht gleich, was Sache ist:
--8--
procedure MimeAuswerten; { RFC = ZConnect }
begin
with hd.mime do
begin
qprint:=encoding=encQP;
b64:=encoding=encBase64;
if ctype in [tMultipart,tMessage,tText] then
hd.typ:='T'
else
hd.typ:='B';
(* no charset conversion for MIME multipart messages *)
mpart:=ctype=tMultipart;
binaer:=hd.typ='B';
convcharset:=not (mpart or binaer or
(ctype=tMessage) or
(subtype='html') or
(subtype='richtext') or
(subtype='enriched'));
if convcharset then
begin
if charset='' then
charset:=RFC_CharsetName(cs_win1252)
else if not supported_charset(LStr(charset)) then
begin
hd.error:='Unsupported character set: '+charset;
hd.charset:=ZC_CharsetName(charset); { = CHARSET: charset }
end;
end;
charset:=LStr(charset);
end;
end;
--8--
Und wenn man zukünftig zu diesem Thema nochmal was ändern will, braucht
man wirklich nur noch dort einzugreifen.
Zu text/html relativ ergiebig für einen Überblick ist:
[RFC2854]
Ah ja, das hatte ich noch nicht, danke.
Michael
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Content-Transfer-Encoding: binary
Michael Heydekamp ([EMAIL PROTECTED]) schrieb: Wie Du bereits angedeutet hast, sind nur Softbreaks zulässig, ansonst sind hard line-breaks so wie sie auftauchen codiert und decodiert, also =D0=0A (bzw. umgekehrt) oder nur =0D oder nur =DA, damit der Inhalt unabhängig von den Regeln des Empfangssystem auf einem anderen System angezeigt werden kann oder sonstwas eben. Wird vermutlich so sein, aber ich will trotzdem mal versuchen, einen Beleg dafür zu finden. zip--- Freed BorensteinStandards Track[Page 22] [...] RFC 2045 Internet Message BodiesNovember 1996 WARNING TO IMPLEMENTORS: If binary data is encoded in quoted- printable, care must be taken to encode CR and LF characters as =0D and =0A, respectively. In particular, a CRLF sequence in binary data should be encoded as =0D=0A. Otherwise, if CRLF were represented as a hard line break, it might be incorrectly decoded on platforms with different line break conventions. [...] zap--- -- Salut _)oachim FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Content-Transfer-Encoding: binary
Joachim Merkel [EMAIL PROTECTED] wrote on 03.07.04: [Ich biege das jetzt mal um nach c.f.dev] Michael Heydekamp ([EMAIL PROTECTED]) schrieb: 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, Scheint mir eine realistische Herangehensweise, wenn man XP als Ende der Empfangskette betrachtet. Ob sich für den Weiterversand als Original daraus mögliche Folgen ergeben scheint mir insofern nicht erheblich, da XP den CTE-Header sowieso immer schon selbst setzt. Zumal sich auch gar keine ergeben. Ignorieren heißt ja nicht, daß er weggeworfen wird, sondern daß sich aus dem Inhalt des Headers keine Konsequenzen ergeben. 7/8bit und binary werden hinsichtlich der Konvertierung einfach gleichbehandelt, da es binary im eigentlichen Sinne (noch) gar nicht gibt und der UUZ ohnehin nur zeilenorientiert arbeiten kann. Im Grunde dreht sich, wenn ich es richtig sehe, alles um das Setzen des Typs in diesen Anweisungen in 'MimeAuswerten': --8-- qprint:=ismime and (encoding=encQP); b64:=ismime and (encoding=encBase64); binary:=ismime and (not (ctype in [tText,tMultipart,tMessage]) or ((encoding=encBinary) and (ctypetText))); hd.typ:=iifc((binary or b64) and (ctypetText),'B','T'); --8-- D.h. übersetzt, daß folgende Nachrichten derzeit als TYP: BIN geflagged und entsprechend behandelt werden (wobei entsprechend behandelt heißt: keine Charset-Konvertierung, kein Anhängen von CRLF): 1. Alle mit CTE base64 deklarierten Singlepart-Nachrichten, die nicht dem Content-Type text/* angehören (message/*, application/*, image/* usw.). 2. Alle mit CTE 7bit, 8bit oder quoted-printable deklarierten Singlepart-Nachrichten, die nicht dem Content-Type text/* oder message/* angehören. 3. Alle mit CTE binary deklarierten Single- und Multipart-Nachrichten, die nicht dem Content-Type text/* angehören. Irgendwie kommt mir der Code etwas wirre vor, ich bin noch nicht sicher, ob ich gedanklich alle Fälle richtig erfaßt habe. Und daß in 1. nur auf base64 und nicht auf qp geprüft wird, ist im Grunde doch auch nicht richtig. Die Art der Codierung spielt für die Frage, ob es sich um eine (codierte) Binärnachricht handelt, doch überhaupt keine Rolle. qp-codierte Binärmails wären also bisher nicht als TYP: BIN geflagged worden. Eigentlich wollte ich schon den geänderten Code posten, aber ich will das doch lieber nochmal überdenken und vor allem testen. 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. Mime ohne Header im Body gibts nicht. Na ja, die wären nach der base64-Decodierung ja da... Aber schon richtig, der Fall ist ohnehin nicht zulässig: --8-- [...] If an entity is of type multipart the Content-Transfer- Encoding is not permitted to have any value other than 7bit, 8bit or binary. Even more severe restrictions apply to some subtypes of the message type. --8-- 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. [...] Wie Du bereits angedeutet hast, sind nur Softbreaks zulässig, ansonst sind hard line-breaks so wie sie auftauchen codiert und decodiert, also =D0=0A (bzw. umgekehrt) oder nur =0D oder nur =DA, damit der Inhalt unabhängig von den Regeln des Empfangssystem auf einem anderen System angezeigt werden kann oder sonstwas eben. Wird vermutlich so sein, aber ich will trotzdem mal versuchen, einen Beleg dafür zu finden. Letzte Bemerkung für den Moment: Mir ist eingefallen, daß wir uns über die Behandlung echter Binaries im UUZ schon deshalb keine Gedanken machen müssen, weil schon die Clients da nicht mitspielen: Im Bemühen, dem UUZ eine UUCP-gerechte Nachricht vorzulegen, verändert mindestens UKAW nämlich ebenfalls EOLs (es konvertiert CRLF nach LF, die der UUZ anschließend wieder nach CRLF umwandelt). Das würde es dann wohl auch bei Binärdaten machen... Und zuguterletzt habe ich noch einen Bug bei dem Ganzen gefunden: Irgendwie habe ich es - unabsichtlich natürlich - hinbekommen, daß der UUZ bei ausgehenden Singlepart-Binaries (i auf Userbrett, Schalter Binärnachrichten als MIME-Attachments unter C/O/E/V deaktiviert) keine MIME-Header mehr setzt. Michael FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
