nicht angemeldet
HTTP-Server Auswertung von multipart/form-data
Hallo,
mein JAVA-HTTP-Server[1] kann schon relativ viel. GET mit Query-Parameterübernahme aus URI-Query, POST enctype="application/x-www-form-urlencoded" mit Query-Parameterübernahme aus URI-Query und POST-Query und POST enctype="multipart/form-data" mit Query-Parameterübernahme aus URI-Query und Multipart-POST-Query. Hier habe ich ein Problem.
Folgender Multipart-Teil kommt beispielsweise nach Absenden eines Formulars an:
-----------------------------7d53c93420126
Content-Disposition: form-data; name="name01"
Axel Richter
-----------------------------7d53c93420126
Content-Disposition: form-data; name="ta01"
Der Inhalt
des Textfeldes
-----------------------------7d53c93420126
Content-Disposition: form-data; name="sex"
male
-----------------------------7d53c93420126
Content-Disposition: form-data; name="attachment"; filename="C:\Test.txt"
Content-Type: text/plain
Das ist nur ein Test
über zwei Zeilen.
-----------------------------7d53c93420126
Content-Disposition: form-data; name="Submit01"
Absenden
-----------------------------7d53c93420126--
siehe http://www.faqs.org/rfcs/rfc1867.html
Zeilenschaltungen sind immer CRLF.
Boundary ist im Beispiel: ---------------------------7d53c93420126
Das Auseinandernehmen des Multiparts habe ich so gelöst:
1. Aufteilen der Parts am boundary
Für alle Parts:
2. Suchen des Strings "name=" und übernehmen des nachstehenden Strings als Feldname
3. Suchen des Strings "filename=" und übernehmen des nachstehenden Inhalts als Dateiname -> Spezielle Behandlung des Parts als Dateiinhalt
4. Übernehmen des Inhalts ab CRLFCRLF bis CRLF-- als Feldinhalt
Spezielle Behandlung des Parts als Dateiinhalt:
3.1 Suchen des Strings "Content-Type:" und übernehmen des nachstehenden Inhalts als DateiInhaltsTyp.
3.2 Übernehmen des Inhalts ab CRLFCRLF bis CRLF-- als Dateiinhalt.
Das Problem ist die Begrenzung der Inhalte durch CRLF--. Diese Zeichenkombination kann, relativ häufig sogar, in Textdateien und auch in TextAreas vorkommen, wodurch meine Methode der "Inhaltsfindung" natürlich ausgehebelt würde.
Wie kann man das Problem lösen?
Eine Idee ist, nach dem Aufteilen der Parts, jedem Part am Ende, also nach den "--", noch irgendwelche Zeichen anzufügen, so dass man dann eine Endposition CRLF--xxx hätte, die nicht so häufig als Dateiinhalt vorkommt. Welche Zeichen wären da günstig? Ich würde jetzt einfach die boundary wieder anfügen.
Oder gibt es da bereits eine genormte Vorgehensweise?
viele Grüße
Axel
[1] Der Server soll zur Veranschaulichung des HTTP-Protokolls dienen.
-
hi,
Boundary ist im Beispiel: ---------------------------7d53c93420126
Das Auseinandernehmen des Multiparts habe ich so gelöst:
- Aufteilen der Parts am boundary
gut, damit bleiben also schon mal nur noch die teile "dazwischen" übrig - als parts, die dann einzeln abgearbeitet werden können.
Für alle Parts:
2. [...]
3. [...]sollten keine probleme bereiten, denke ich.
- Übernehmen des Inhalts ab CRLFCRLF bis CRLF-- als Feldinhalt
nach dem du bis zum namen gelesen hast, ist der feldinhalt doch jetzt einfach der _rest_ dieses parts, oder etwas nicht?
also nur vorne doppeltes CRLF und hinten folgendes einfaches noch abtrennen. ein "lesen von - bis" sehe ich hier gar nicht mehr - es ist schlicht und einfach der _rest_ dieses parts nach name="..."Spezielle Behandlung des Parts als Dateiinhalt:
wenn du erst 4. abgearbeitet hast, hast du jetzt nur noch
Content-Type: text/plain
Das ist nur ein Test
über zwei Zeilen.als "feldinhalt". das es kein feld, sondern ein attachment ist, weißt du bereits auf grund von 3.
3.1 Suchen des Strings "Content-Type:" und übernehmen des nachstehenden Inhalts als DateiInhaltsTyp.
3.2 Übernehmen des Inhalts ab CRLFCRLF bis CRLF-- als Dateiinhalt.
also auch hier wieder der _rest_ dieses parts - ab "Content-Type: ...CRLFCRLF", und CRLF am ende entfernen.
Das Problem ist die Begrenzung der Inhalte durch CRLF--. Diese Zeichenkombination kann, relativ häufig sogar, in Textdateien und auch in TextAreas vorkommen, wodurch meine Methode der "Inhaltsfindung" natürlich ausgehebelt würde.
Wie kann man das Problem lösen?
ich sehe dein problem nicht.
deine notendigkeit der inhalts"findung" kann ich hier schlicht nicht nachvollziehen. warum nimmst du nicht einfach den _rest_ des parts, wozu willst du noch irgendwas "suchen"?gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }-
Hallo,
ich sehe dein problem nicht.
deine notendigkeit der inhalts"findung" kann ich hier schlicht nicht nachvollziehen. warum nimmst du nicht einfach den _rest_ des parts, wozu willst du noch irgendwas "suchen"?Ja, danke auch Dir. Das Problem sehe ich jetzt auch nicht mehr ;-)), siehe mein Posting an Sven.
viele Grüße
Axel
-
Moin!
Das Auseinandernehmen des Multiparts habe ich so gelöst:
- Aufteilen der Parts am boundary
Für alle Parts: - Übernehmen des Inhalts ab CRLFCRLF bis CRLF-- als Feldinhalt
Es gibt kein CRLF--, wenn du den Part am Boundary aufgeteilt hast. Es gibt allenfalls noch ein letztes CRLF.
Spezielle Behandlung des Parts als Dateiinhalt:
3.1 Suchen des Strings "Content-Type:" und übernehmen des nachstehenden Inhalts als DateiInhaltsTyp.
3.2 Übernehmen des Inhalts ab CRLFCRLF bis CRLF-- als Dateiinhalt.Das ist auch nicht korrekt. Je nach Mimetyp wird der Dateiinhalt codiert. text/plain natürlich nicht. Die Codierung steht im Part-Header. Und der Dateiinhalt geht natürlich wieder bis zur Part-Boundary.
Das Problem ist die Begrenzung der Inhalte durch CRLF--. Diese Zeichenkombination kann, relativ häufig sogar, in Textdateien und auch in TextAreas vorkommen, wodurch meine Methode der "Inhaltsfindung" natürlich ausgehebelt würde.
Die Boundary _insgesamt_ ist so zu wählen, dass dieser String nicht im Inhalt vorkommt. Das ist Aufgabe des Browsers. Außerdem steht die gewählte Boundary ja im Header der Multipart-Nachricht. Damit kannst du die einzelnen Teile ja aufsplitten.
Eine Idee ist, nach dem Aufteilen der Parts, jedem Part am Ende, also nach den "--", noch irgendwelche Zeichen anzufügen, so dass man dann eine Endposition CRLF--xxx hätte, die nicht so häufig als Dateiinhalt vorkommt. Welche Zeichen wären da günstig? Ich würde jetzt einfach die boundary wieder anfügen.
Die Startmarke eines Parts ist "--$BOUNDARYSTRING", das Ende einer Reihe von Parts wird mit "--$BOUNDARYSTRING--" gekennzeichnet. Wozu brauchst du da jetzt noch irgendeine Markierung?
- Sven Rautenberg
-
Hallo,
Es gibt kein CRLF--, wenn du den Part am Boundary aufgeteilt hast. Es gibt allenfalls noch ein letztes CRLF.
Nicht, wenn man am boundary-String, der vom Browser mitgesendet wird aufgeteilt hat, wie ich. Aber natürlich kann man auch am --$BOUNDARYSTRING aufteilen. Danke für den Hinweis. Ich wusste, dass ich da mal wieder eine Gedanken-Edlos-Schleife im Hirn hatte.
3.2 Übernehmen des Inhalts ab CRLFCRLF bis CRLF-- als Dateiinhalt.
Das ist auch nicht korrekt. Je nach Mimetyp wird der Dateiinhalt codiert. text/plain natürlich nicht.Bevor ich da jetzt wieder den Wald vor Bäumen nicht sehe, frage ich hier nochmal nach.
Du meinst die 7-Bit-Kodierung für das mailto:-Protokoll?
Ich habe nämlich bei allen meinen bisherigen Versuchen (image/gif, image/jpeg, application/octet-stream) nie einen Content-Transfer-Encoding: header in den Parts gesehen (ja ich habe bisher nur mit IE unter Windows getestet ;-)), will allerdings auch _nur_ HTTP nutzen.Die Boundary _insgesamt_ ist so zu wählen, dass dieser String nicht im Inhalt vorkommt. Das ist Aufgabe des Browsers. Außerdem steht die gewählte Boundary ja im Header der Multipart-Nachricht. Damit kannst du die einzelnen Teile ja aufsplitten.
Mach/te ich ja ;-)), allerings nicht an "--".concat(boundary), mach ich aber jetzt.
Die Startmarke eines Parts ist "--$BOUNDARYSTRING", das Ende einer Reihe von Parts wird mit "--$BOUNDARYSTRING--" gekennzeichnet. Wozu brauchst du da jetzt noch irgendeine Markierung?
Ja, danke, jetzt brauch ich die nicht mehr.
viele Grüße
Axel
- Aufteilen der Parts am boundary