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
