+ Antworten
Ergebnis 1 bis 2 von 2

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

Eine Diskussion über Eigener Java-Server, Bilder per HTTP-Post übertragen im Forum Technik Ecke. Teil des Off Topic-Bereichs; Guten Tag Genossen... Folgendes Problem stellt sich mir im Moment: Wir müssen einen netten kleinen Webserver in Java programmieren, welcher ...

  1. #1
    Oberstabsfeldwebel
    Avatar von .deviant
    Registriert seit
    01.06.2004
    Alter
    29
    Beiträge
    5.663

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

    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 :/

  2. #2
    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
    Zitat Zitat von [URL="http://www.faqs.org/rfcs/rfc1867.html"]RFC 1867[/URL]
    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.

+ Antworten

Ähnliche Themen

  1. Bilder per Zeichen
    Von James im Forum OFF-Topic
    Antworten: 23
    Letzter Beitrag: 26.10.2008, 13:05

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •