Neue UUZ-Testversion v3.40.1b (was: Content-Transfer-Encoding: binary)

2004-07-09 Diskussionsfäden Michael Heydekamp
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

Re: Content-Transfer-Encoding: binary

2004-07-07 Diskussionsfäden Joachim Merkel
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

Re: Content-Transfer-Encoding: binary

2004-07-07 Diskussionsfäden Michael Heydekamp
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

Re: Content-Transfer-Encoding: binary

2004-07-04 Diskussionsfäden Joachim Merkel
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

Re: Content-Transfer-Encoding: binary

2004-07-03 Diskussionsfäden Michael Heydekamp
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