Eigener Java-Server, Bilder per HTTP-Post übertragen

[.deviant]

Guten Tag Genossen...
Folgendes Problem stellt sich mir im Moment: Wir müssen einen netten kleinen Webserver in Java programmieren, welcher grundsätzlich per GET alles erledigen kann, aber aus Gründen der Ästhetik unterstützt unserer auch POST-Anfragen (Sicherheit wird in dieser Projektarbeit zwar nicht gefordert, aber viele Sachen sind toller codiert und Passwörter im Klartext ballern halt auch nich so richtig...)
Nun wollen wir als kleines Schmankerl (hrhr ) noch einen Bilderupload anbieten, aber hier stirbts uns dann unter den Händen weg .^^
Also: GET-Anfragen werden toll behandelt, auseinandergemopst und im Server verarbeitet und zurückgeschickt. Auch normale multipart/form-data POST Formulare werden soweit toll behandelt, naja unser Ziel ist es dass man per normalem <input type="file"> ein Bild in einem Formular mitschicken soll. Der Parser schluppt dann das Bild aus dem Stream, resized es (vielleicht ) und speichert es dann ab (das mit dem resize ist eher sekundär). Das wär grandios...aber im Moment nicht sehr greifbar.
Die ganzen Daten über Browser, System usw, alles was so ein kleiner POST-Header so weiß, wird eh rausgestript. Danach folgen durch die Boundaries getrennt ja die einzelnen Variablen...und den Müll den wir da kriegen...weil ein Bild ja nicht klartextlastig ist, müssten wir halt irgendwie vernünftig in nen Stream kriegen. Oder so. Naja. Und wir müssten feststellen können, wann denn so'n Bildchen mitkommt...und wann es zu Ende ist. Eiderdaus :/

 

[Osbes]

Besteht das Problem noch? Falls ja:

Ich denke das Problem liegt hier hauptsächlich an euren Vorraussetzungen, daher würde ich gerne wissen was ihr zur Verfügung habt (am besten Code Schnipsel) und wie ihr POST / GET erkennt/verarbeitet.

Zunächst mal zu multipart/form-data

7. Registration of multipart/form-data

The media-type multipart/form-data follows the rules of all multipart
MIME data streams as outlined in RFC 1521. It is intended for use in
returning the data that comes about from filling out a form. In a
form (in HTML, although other applications may also use forms), there
are a series of fields to be supplied by the user who fills out the
form. Each field has a name. Within a given form, the names are
unique.

multipart/form-data contains a series of parts. Each part is expected
to contain a content-disposition header where the value is "form-
data" and a name attribute specifies the field name within the form,
e.g., 'content-disposition: form-data; name="xxxxx"', where xxxxx is
the field name corresponding to that field. Field names originally in
non-ASCII character sets may be encoded using the method outlined in
RFC 1522.

As with all multipart MIME types, each part has an optional Content-
Type which defaults to text/plain. If the contents of a file are
returned via filling out a form, then the file input is identified as
application/octet-stream or the appropriate media type, if known. If
multiple files are to be returned as the result of a single form
entry, they can be returned as multipart/mixed embedded within the
multipart/form-data.

Each part may be encoded and the "content-transfer-encoding" header
supplied if the value of that part does not conform to the default
encoding.

File inputs may also identify the file name. The file name may be
described using the 'filename' parameter of the "content-disposition"
header. This is not required, but is strongly recommended in any case
where the original filename is known. This is useful or necessary in
many applications.

Somit könnt ihr sehr einfach die einzelnen Daten extrahieren indem ihr euch nach den einzelnen Kodierungen richtet.