Joachim Merkel <[EMAIL PROTECTED]> wrote on 21.07.04:
> Michael Heydekamp ([EMAIL PROTECTED]) schreibt:
> [Content-Header und deren Parameter auswerten]
>> Und jetzt bin ich etwas unschluessig, was ich tun soll und wie ich
>> es im Detail tun soll. Falls mir jemand auf die Spruenge helfen
>> kann und will...
> Mir fehlt leider der Überblich bei diesem Thema
In der angehängten Aufstellung fehlte BTW noch multipart/related (RFC
2387). Dieser Typ besitzt z.B. einen eigenen Parameter "type=", der mit
dem "type=" bei application/octet-stream inhaltlich wenig bis nichts zu
tun hat und daher - wenn überhaupt - auch anders auszuwerten wäre.
Nur so am Rande.
> und ob sich wirklich alle dran halten oder nicht wieder "best praxis"-
> Wissen erforderlich ist.
Das kommt mit Sicherheit auch noch dazu.
> Aber zumindest werde ich Deine Überlegungen dazu künftig mit beachten,
> wenn ich mich wieder mit RFCs beschäftige. [...]
Tja, ich müßte erstmal welche haben. Noch stelle ich für mich
Informationen zusammen, um einen Überblick zu gewinnen.
>> Wenn man sich entschliesst, den U-Content-Type prinzipiell
>> unveraendert zu schreiben und dort nur die relevanten Parameter wie
>> "charset=" auszuwerten und ggf. zu korrigieren - was mir derzeit das
>> Sinnvollste erscheint - dann waere zumindest die gemeinsame
>> Zusammenstellung einer Liste der Parameter hilfreich, die man als
>> relevant ansieht bzw. die objektiv fuer den UUZ relevant sind - und
>> zwar eine Liste *nur* dieser relevanten Parameter.
> Die Anzahl der unterstützten Typen wird man generell knapp halten
> müssen
Na ja, "unterstützen" im eigentlichen Sinne tut der UUZ überhaupt keinen
dieser Parameter. Es geht halt darum, alle (auch nicht unterstützte
bzw. gänzlich unbekannte) Parameter zu schreiben, aber in klar
definierten Einzelfällen - Beispiel "charset=" - notwendige Anpassungen
vorzunehmen.
Diese Fälle vollständig zusammenzustellen, darum geht es. Und meine
Vermutung ist, daß wir zukünftig letztlich weniger Parameter konkret
auszuwerten haben als wir es derzeit tun.
> und womöglich bei abnehmender Wichtigkeit der Typen sich auf eine
> jeweils verringerte Anzahl der auszuwertenden Parameter einigen
> müssen, wird wohl nicht anders gehen.
Bisher mußten ja nur deshalb so "viele" (aber immer noch viel zu wenig)
ausgewertet werden, weil der Content-Type-Header immer komplett neu
erzeugt wurde, statt einen ggf. vorhandenen zu übernehmen und evtl.
anzupassen.
Mit "Auswerten" meine ich die Prüfung auf einen konkreten Parameter nach
dem Prinzip "if parname='boundary' then hd.boundary:=[...]". Nur die
Parameter, die so ausgewertet wurden, blieben bisher in zu-Richtung
erhalten, alle übrigen fielen unter den Tisch. Das kann's ja nicht
sein.
Schon gar nicht vor dem Hintergrund, daß mir vorschwebt, mit FreeXP mal
ein "echtes" N/W/* machen zu können, ohne die ursprüngliche Struktur
(Content-Type, Boundary usw.) zu verletzen und durch eine eigene zu
ersetzen. Darauf wäre dann wenigstens der UUZ schon mal vorbereitet.
Würden wir zukünftig eh den kompletten Header schreiben, müssen nur noch
die Parameter (wie oben) ausgewertet werden, bei denen evtl. eine
Anpassung nötig ist oder aus deren Existenz andere Schlüsse zu ziehen
sind (z.B. wenn Parameter "name=" in Content-Type vorhanden, dann dort
verwerfen und stattdessen Parameter "filename=" in Content-Disposition
mit identischem Inhalt erzeugen).
Ich bin mir einfach auch noch nicht darüber im klaren, mit welcher
Datenstruktur ich arbeiten soll. Entweder liest man alle Parameter
(Bezeichner und Wert jeweils in einem Record) in eine verkettete Liste
oder sowas ein und baut daraus später wieder den Header zusammen, oder
man behandelt das als einen gesamten String.
Da ich aber natürlich hier nicht auf einen Pascal-String beschränkt sein
will, läuft's wieder auf ein array of char mit 65500 Zeichen hinaus.
Aber da sehe ich das Problem, wenn sich die Stringlänge (z.B. beim
Austausch von "charset=UTF-8" durch "charset=ISO-8859-15") ändern
sollte, daß das dann nicht geht, wenn ich mir vorher nur den Speicher
für die aktuelle Länge des Headers reserviert habe.
Und jedes Mal die vollen 64k zu holen wäre pure Verschwendung,
vorsichtshalber ein paar Bytes (wieviel?) mehr als die aktuelle Länge
hingegen willkürlich und nie sicher, daß es reicht. Ja gut, doppelt
soviel sollte wohl immer reichen, aber solche "Kalkulationen" sind auch
irgendwie Murks.
Ich fange einfach mal an, konkret ein paar Dinge zusammenzustellen.
Falls jemand was ergänzen/korrigieren möchte, bitte ich darum. :)
-uz: Content-Type und Content-Disposition parsen und ...
1) "name=" oder "x-filename=" in Content-Type => "FILE:" (Pfad
entfernen)
2) "x-date=" in Content-Type => "DDA:" (aber nur, wenn Dateiname
vorhanden)
3) "boundary" => "X-XP-Boundary:" (nur Multipart)
4) "name=" in Content-Disposition => "FILE:" (Vorrang vor evtl.
Dateinamen in Content-Type; Pfad entfernen)
5) "modification-date=" in Content-Disposition => "DDA:" (Vorrang
vor evtl. Datum in Content-Type; nur, wenn Dateiname
vorhanden)
6) "charset=" auswerten und wenn konvertierbar, konvertieren (nur
text/plain); wenn nicht konvertierbar oder text/* <> plain,
Wert => CHARSET
6) Content-Type und Content-Disposition mit originalem Inhalt und
Prefix "U-" schreiben
-zu: U-Content-Type und U-Content-Disposition parsen und ...
1) "name=" oder "x-filename=" in U-Content-Type entfernen (kommt
als "filename=" nach Content-Disposition)
2) "x-date" in in U-Content-Type entfernen (kommt als
"modification-date" nach Content-Disposition)
3) Alle Parameter entfernen, die a) bekannt sind und b) im
jeweiligen Kontext nicht standardisiert sind ("x-" hingegen
erhalten)
(Wollen/können wir das?!?!?)
4) CHARSET: und X-Charset wie bisher auswerten, ggf. konvertieren
(Regeln dazu siehe UUZ_TEST.TXT) und etwaig bereits
vorhandenen Parameter "charset=" in Content-Type korrigieren
bzw. ergänzen, wenn nicht vorhanden (nur text/*)
5) X-XP-Boundary quoten und => "boundary="
6) FILE: => "filename=" in Content-Disposition
7) DDA: => "modification-date" in Content-Disposition (nur wenn
nicht bereits vorhanden)
8) Alle übrigbleibenden Parameter 'as is' übernehmen, dabei ggf.
fehlende Leerzeichen nach ";" ergänzen und Header in voller
Länge (gefaltet) schreiben. Klären: "inline" in "attachment"
ändern?
9) Sind gar keine Content-*-Header vorhanden, diese bei Bedarf
aus X-XP-Boundary, DDA: und FILE: erzeugen (kommt z.B. bei
Binär-Attachments vor, die mit "i" auf Userbrett erzeugt
wurden) und als "attachment" deklarieren.
10) Bei message/partial ist immer CTE 7bit zu setzen!
Your turn. :)
Michael
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
