WebService für <img>-tags in https Kontext



  • Guten Morgen,

    ich plane gerade ein kleines Projekt.
    Über Http-Get anfragen sollen Bilder generiert werden, abhängig von url-Parametern

    i.e. :

    https://xxx.yyy/image?param=123456789, soll dann einen bytestream zurückgeben.

    in einer webseite soll dann dieses Bild über ein image-Tag eingebunden werden ...

    i.e. :

    <img src="https://xxx.yyy/image?param=123456789" />
    

    Ehe ich damit anfange, wollte ich 2 große Probleme betrachten, welche ich im Vorfeld sehe :
    (1) mime-type
    Ich werde die Bilder auf dem Server wohl als png kodieren, aber wie bekommt der Server die Kodierung mit? Die Bibliothek welche mir die Bilder generiert wird ja hoffentlich den richtigen mime-type in den Out-Stream packen... (ja/nein/vielleicht)?
    (2) ssl Kontext
    Wenn ich diese Bilder in einer https-Seite einbinde, und den web-Service über http-get veröffentliche, dann bekomme ich doch sicherlich die Warnung :
    "Diese Seite enthält sowohl sichere wie auch unsichere Objekte".
    Das möchte ich natürlich nicht ....
    Reicht es in diesem Fall, den webService über https zu veröffentlichen?
    Welches Zertifikat nehme ich denn da? Einfach jenes, welches eh für den Server gilt auf dem Service läuft?

    Ich hoffe, jemand hat mit so etwas schon ein paar Erfahrungen und kann mich in einigen Punkten ein wenig erhellen ...

    PS : die webseiten dynamisch zu generieren, kommt aus technischen Gründen nicht in Frage. Auch soll der Service für mehrere Seiten benutzt werden. Einige davon sind statisch, andere dynamisch.

    Viele Grüße 😉



  • -Emil- schrieb:

    (1) mime-type
    Ich werde die Bilder auf dem Server wohl als png kodieren, aber wie bekommt der Server die Kodierung mit? Die Bibliothek welche mir die Bilder generiert wird ja hoffentlich den richtigen mime-type in den Out-Stream packen... (ja/nein/vielleicht)?

    Bilder kann der Browser idR automagisch erkennen. Da ist ein Mime Type nicht zwingend notwendig. Aber im idealfall schickst du natürlich den richtigen MimeType mit - ob das deine Bibliothek automatisch macht, kann ich dir natürlich nicht sagen.

    (2) ssl Kontext
    Wenn ich diese Bilder in einer https-Seite einbinde, und den web-Service über http-get veröffentliche, dann bekomme ich doch sicherlich die Warnung :
    "Diese Seite enthält sowohl sichere wie auch unsichere Objekte".
    Das möchte ich natürlich nicht ....
    Reicht es in diesem Fall, den webService über https zu veröffentlichen?
    Welches Zertifikat nehme ich denn da? Einfach jenes, welches eh für den Server gilt auf dem Service läuft?

    Du brauchst ein gültiges Zertifikat für diese Domain. Let's Encrypt kann dir da helfen.



  • Shade Of Mine schrieb:

    Du brauchst ein gültiges Zertifikat für diese Domain. Let's Encrypt kann dir da helfen.

    Jup, habe ich da ...
    Ich werde mich ab Samstag mal ranmachen.
    Mal sehen in welche Fallstricke ich da noch so renne, ich poste meine Erfahrungen 😉



  • Hallo Emil,

    mit welcher Skriptsprache baust du den Webservice, womit generierst du die Bilder?

    In PHP z. B. ist es recht simpel, einen MIME-Typ anzugeben. Man kann bequem (solange keine Ausgaben getätigt wurden) HTTP-Header angeben.



  • Nico D. schrieb:

    mit welcher Skriptsprache baust du den Webservice, womit generierst du die Bilder?

    Alsoooo, Ich wollte ja feedback geben 😉 ...

    - webservice ist fertig
    - implementiert in java ( weil die Bibliothek, welche die Hauptarbeit erledigt nur in java verfügbar ist, und ich keine Lust hatte aus C++ oder C# (meine "preferred languages"), java aufzurufen)
    - mimetype war nicht nötig, ich gebe

    MediaType.APPLICATION_OCTET_STREAM
    

    zurück und schreibe den byte-stream (das png-Bild) direkt in die response

    - um die https-Geschichte habe ich mich gedrückt 🙄
    ( alle webServices laufen in seperaten containern hinter einem reverse-proxy, dieser macht dann https)



  • -Emil- schrieb:

    MediaType.APPLICATION_OCTET_STREAM
    

    Ich bin mir ziemlich sicher, dass das genau diesen HTTP-Header generiert. Hast du das mal geprüft?