Michael Heydekamp ([EMAIL PROTECTED]) schreibt:
[...]
> 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.
So hatte ich das auch verstanden, bisher wurde fast alles weggeworfen.
> 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.
Liest sich plausibel, auch der Wunsch nach einem eindeutigen
Boundary-Delimiter wird bisher �bergangen.
Ob man sich unter einer ZConnect-Box immer Freunde schafft, alles
so weiterzuleiten was die Gates abliefern, bleibt immer fragw�rdig.
PM hat sich seit jeher nicht damit anfreunden wollen, XP zur
Gateway-Software zu stilisieren.
[...]
> 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.
Ich verstehe jetzt nicht genau, was Du ansprichst.
Um die Parameter zu parsen hast Du doch den Header komplett
erstmal als String einzulesen.
> 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.
�nderungen k�nnen vielleicht in verkettete Strings abgespeichert
werden. Zun�chst also wird Speicher mit der L�nge des vorhandenen
Strings zus�tzlich reserviert. Wenn also eine �nderung vorgenommen
wird, wird der String bis an die Stelle kopiert wo die �nderung
vorgenommen wird. Dann wird die �nderung reinkopiert. Wenn diese
l�nger ist als Speicher angefordert wurde, wird nur der Teil
umkopiert, der reinpa�t, dann wieder dasselbe und nachher wird
alles der Reihe nach auf die Platte geschrieben.
> 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.
Besser w�re, die Sache kann (etwas) dynamisch(er) passieren.
> 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 ...
[...]
> 6) Content-Type und Content-Disposition mit originalem Inhalt
^ soll wahrscheinlich 7) hei�en
> und Prefix "U-" schreiben
> -zu: U-Content-Type und U-Content-Disposition parsen und ...
[...]
> 3) Alle Parameter entfernen, die a) bekannt sind und b) im
> jeweiligen Kontext nicht standardisiert sind ("x-"
> hingegen erhalten)
> (Wollen/k�nnen wir das?!?!?)
"x-"-Parameter sollen dem Empf�nger bekannt sein, sonst kann man sie
sich sparen.
[...]
> Your turn. :)
Kann eine Weile dauern bei mir, denn zum einen ist der erreichte
Stand bei XP in punkto MIME schon um einiges besser als ich es
ben�tige, aberin Hinblick auf die weitere Dokumentation werde
ich nat�rlich auch darauf achten.
--
Salut
_)oachim
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
