Bild aus DB in HTML-Seite einbinden

[Delbor]

Hi zusammen
Zurzeit arbeite ich mich in Webserver-Programmierung ein. Um Missverständnissen vorzubeugen: mit Webserver ist hier die auf dem Webspace gehostete Anwendung gemeint, die HTML-Seiten auf Anfrage zusammenbaut und ausliefert.
Dabei stellt sich mir zurzeit eine Frage:
Mein Programm wird in der Lage sein, einzelne Textbausteine der Webseite auszuwechseln/individuell einzufügen. Zum Beispiel dass CSS-Sheet: Die Dateiangabe im HTML-Dokument wird es nicht mehr geben. Stattdessen wird das CSS aus einer Datenbank gelesen und vom Programm an der richtigen Stelle als String eingefügt.
Dasselbe soll mit den Bildern geschehen. Nur  -  hier kann ich nicht einfach den in HTML geschriebenen Text in die DB schreiben, bzw. daraus lesen, da dieser auf eine Datei auf der Festplatte verweist, zum Beispiel so:

<div id="img1">&nbsp;<img alt="DelborPunktCH" src="./Images/jpeg150/DSC_5751.jpg"/></div>

Obige Zeile würde/könnte so von meinem Programm also in die HTML-Seite geschrieben werden, bevor diese an den Browser ausgeliefert würde. Die Sache hat nur einen ziemlich kräftigen Haken: Da das Bild aus einer DB stammt, ist dieses unter dem angegebenen Pfad nicht vorhanden.
Ich müsste das Bild also aus einem Stream direkt dem img-Element zuweisen können  -  und dies mit HTML-Mitteln, da ich an dieser Stelle noch kein Javascript einsetzen möchte. ('Aktive Inhalte' können auch in modernen Browsern immer noch ausgeschaltet werden).

Ich hoffe, ich habe mein Problem verständlich genug geschildert.

Eine Idee dazu hätte ich: Wenn an src statt eines Pfades auch ein Hexstring übergeben werden könnte, wäre genau dies die Lösung. Leider habe ich bisher nichts über alternative Zuweisungsmöglichkeiten gefunden.

Gruss
Delbor

[Siri]

Hallo,

Ich müsste das Bild also aus einem Stream direkt dem img-Element zuweisen können  -  und dies mit HTML-Mitteln, da ich an dieser Stelle noch kein Javascript einsetzen möchte. ('Aktive Inhalte' können auch in modernen Browsern immer noch ausgeschaltet werden).

Man kann durchaus auch schreiben <img src="streamservice.html?id=1234" /> Du musst halt was entsprechendes Serverseitig hinterlegen, das den Stram dann ausliefert. Hier mal ein Beispiel für Java/Servlets (weiß nicht was du benutzt und mit PHP kenne ich mich nicht aus). Mit den Suchbegriffen "Straeming Image" + DeineServerSprache sollte dir Google weiterhelfen.

Viele Grüße
Siri

[Delbor]

Hi  Siri

Ich hab nebenbei ein klitzekleines Problemchen  -  meine Englischkenntnisse sind mehr schlecht als recht. Nur, wozu gibts den Google-Übersetzer?
Folgende Zeilen fand ich recht aufschlussreich:

Assuming that you select images by the database key as identifier, use this in your HTML:
<img src="images/123">

src nimmt somit einen String entgegen, der nicht zwangsläufig ein Pfad sein muss.

Im zweiten Beitrag  heisst es:

you can use byte of array type for image from servlet if it is there in Database of Blob type.

Da die DB ein MySQL-Server ist, lese ich da die Daten in einen Blobstream aus. Wenn ich die Angaben auf der Seite nicht komplett falsch verstanden habe, kann ich diesen, bzw. dessen Inhalt, also problemlos an src zuweisen.

Man kann durchaus auch schreiben <img src="streamservice.html?id=1234" /> Du musst halt was >entsprechendes Serverseitig hinterlegen, das den Stram dann ausliefert.

Das irritiert mich jetzt aber doch etwas. So, wie ich dich hier verstehe, wird hier eine Datei Namens "streamservice.html?id=1234", die den Streaminhalt aus der DB enthält, an src zugewiesen.

Gruss
Delbor

[Siri]

Hallo,

Man kann durchaus auch schreiben <img src="streamservice.html?id=1234" /> Du musst halt was >entsprechendes Serverseitig hinterlegen, das den Stram dann ausliefert.

Das irritiert mich jetzt aber doch etwas. So, wie ich dich hier verstehe, wird hier eine Datei Namens "streamservice.html?id=1234", die den Streaminhalt aus der DB enthält, an src zugewiesen.

Das war nur ein Beispiel. Ich hätte auch schreiben können:
<img src="streamservice?id=1234" />
<img src="streamservice.php?id=1234" />
<img src="streamservice.egawas?id=1234" />

src nimmt schon einen Pfad oder besser gesagt URL entgegen. Entscheidend ist das Mapping. Im Tomcat sieht das für Servlets z.B. so aus:

  
   <servlet>  
        <servlet-name>HelloServlet</servlet-name>  
        <servlet-class>examples.Hello</servlet-class>  
    </servlet>  
    <servlet-mapping>  
        <servlet-name>HelloServlet</servlet-name>  
        <url-pattern>/hello</url-pattern>  
    </servlet-mapping>

Alles was auf die URL www.example.com/hello geht wird auf die Klasse Hello im package examples geleitet, also ein Zusammenhang zwischen URL und "Programm" hergestellt:

   <servlet>  
        <servlet-name>StreamserviceServlet</servlet-name>  
        <servlet-class>examples.StreamService</servlet-class>  
    </servlet>  
    <servlet-mapping>  
        <servlet-name>StreamserviceServlet</servlet-name>  
        <url-pattern>/streamservice</url-pattern>  
    </servlet-mapping>  
  
    oder  
  
    <servlet-mapping>  
        <servlet-name>StreamserviceServlet</servlet-name>  
        <url-pattern>/streamservice.html</url-pattern>  
    </servlet-mapping>

Und das Servlet sorgt dann, wie im vorigen verlinkten Beispiel, für die Auslieferung des Bildes, das du entsprechen aus der Datenbank auslesen musst.

Viele Grüße
Siri

[Tom]

Hello Delbor,

das ist ein ziemlich großer Knoten, den Du hier zu entflechten hast. Du solltest Dir bitte die Zeit nehmen, alle Antworten, die hier die nächsten Tage kommen werden, zu lesen.

Da das Bild aus einer DB stammt,

Man _kann_ BLOBs (Binary large Objects), also auch Bilder, innerhalb einer Datenbank speichern. Das ist vorteilhaft für eine geschlossene Datensicherung. Wenn alles in der DB steht, muss man ja nur die paar Gigabytes der Datenbank sichern :-P

BLOBs in Datenbanken sollte man vermeiden, wenn es geht, und sie diskret als File auf der Platte speichern. Das Filesystem kennt mehr Mechanismen für die Balancierung, als eine Datenbank, denn die ist ja selber i.d.R. Bestandteil des Filesystems.

ist dieses unter dem angegebenen Pfad nicht vorhanden.

Klar. Hier kommt dann beim Apachen der "Rewrite Modus", also die Rewrite Engine ins Spiel. Alle Requests, die z.B. auf "http://ecample.org/image/*", also z.B. auch "http://ecample.org/image/3000789.jpg"  werden auf ein Script umgeleitet, das die Anfrage nach Bild 3000789.jpg bearbeitet und beantwortet.

Dazu wird erst in der DB nachgeschaut, ob der Requestor berechrtigt ist, das Bild zu sehen und dann wird es mittles einer Ausgabefunktion aus einem NICHT DIREKT PER HTTP zugänglichen Verzeichnis an den Client ausgegeben.

Ich müsste das Bild also aus einem Stream direkt dem img-Element zuweisen können  -  und dies mit HTML-Mitteln, da ich an dieser Stelle noch kein Javascript einsetzen möchte. ('Aktive Inhalte' können auch in modernen Browsern immer noch ausgeschaltet werden).

JavaScript hat hier überhaupt nichts zu suchen.
Alles, was Du benötigst, sind serverseitige Techniken.

to be continued!

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Delbor]

Hi Tom,

das ist ein ziemlich großer Knoten, den Du hier zu entflechten hast. Du solltest Dir bitte die Zeit nehmen, alle Antworten, die hier die nächsten Tage kommen werden, zu lesen.

Das das ganze nicht trivial ist, ist mir bewusst. Einmal schon desshalb, weil ich bisher nur Desktopanwendungen entwickelt habe und mich erst kürzlich in Webprogrammmierung einzuarbeiten begonnen habe. Das andere ist, dass man, wie mir beim lesen der Antworten konkreter klar wurde, durch unsorgfältiges Arbeiten gehörigen Murks bauen kann.

BLOBs in Datenbanken sollte man vermeiden, wenn es geht, und sie diskret als File auf der Platte speichern. Das Filesystem kennt mehr Mechanismen für die Balancierung, als eine Datenbank, denn die ist ja selber i.d.R. Bestandteil des Filesystems.

Kürzlich habe ich mir eine (Desktop-)Bilddatenbank gebaut. Das Ding enthält Blobfelder für 3 verschiedene Bildformate: zum einen die originalen RAW-Dateien aus der Kamera mit je ca. 10MB, zum andern Bitmaps, die vorgesehen sind für den Fall, dass Bilder bearbeitet werden müssen; deren Grösse habe ich noch nicht festgelegt, da sie dreimal grösser als die RAW-Bilder bei gleichen Abmessunge sind. Und zu guter letzt habe ich Thumbnails im Jpeg-Format mit 1.2kb, die beim Navigieren durch die DB zum Einsatz kommen. Abschreckend könnte dabei nur sein: Das Einlesen der RAW-Bilder (und herstellen der Thumbnails) dauert eine Ewigkeit (ca. 25 Minuten/200 Bilder).
Für dieses DB-Programm hatte ich mir auch überlegt, nur die Pfade in die DB aufzunehmen.

ist dieses unter dem angegebenen Pfad nicht vorhanden.

Klar. Hier kommt dann beim Apachen der "Rewrite Modus", also die Rewrite Engine ins Spiel. Alle Requests, die z.B. auf "http://ecample.org/image/*", also z.B. auch "http://ecample.org/image/3000789.jpg"  werden auf ein Script umgeleitet, das die Anfrage nach Bild 3000789.jpg bearbeitet und beantwortet.

Beim Apachen ist das geschützte Verzeichnis, soweit ich weiss, .htpAccess  -  unter den IIS ist dies INetpup. Ich hatte mich damals nicht zuletzt auch aus Sicherheitsgründen entschieden, in die DB die Bilder selbst und nicht nur deren Pfade aufzunehmen. Dazu kommt: besonders in den Anfängen hatte ich verschiedene externe Grafikprogramme benutzt und dank einiger dieser 'Spezialisten' gewisse Bilder plötzlich doppelt und dreifach auf der Platte. Dank der DB kann ich mir einen klaren Überblick verschaffen, was ich habe und muss nicht befürchten, dass Löschaktionen auf der Festplatte auch Bilder betreffen, die nicht gelöscht werden dürfen.

Als Webdatenbank habe ich mir nun was ähnliches vorgestellt  -  nur, dass diese wohl nur ausschliesslich Jpegs mit einer grossen Seitenlänge von maximal 1024pxx bei einer Qualitaet unter 100% enthält. Grundsätzlich könnten sich die Bilder auch in einem geschützten Verzeichis befinden. Wichtig ist, dass sie vor Fremdmanipulation geschützt sind, dass sie leicht ausgetauscht und problemlos zwischen ihnen navigiert werden kann.

Gruss
Delbor

[hotti]

hi,

Ich hoffe, ich habe mein Problem verständlich genug geschildert.

Ja ;)

Beachte bitte, dass solche Lösungen eine zusätzliche Serverlast erzeugen! Das kann mit einem sorgsamen Cache-Konzept zwar gemildert, jedoch nicht völlig aus der Welt geschafft werden.

Eine Idee dazu hätte ich: Wenn an src statt eines Pfades auch ein Hexstring übergeben werden könnte, wäre genau dies die Lösung. Leider habe ich bisher nichts über alternative Zuweisungsmöglichkeiten gefunden.

Zwei der Möglichkeiten:

.src zeigt auf eine Ressource, hinter der sich ein serverseitiger Prozess verbirgt, der das Image mit dem passenden Content-Type (image/gif, image/png,...) ausliefert

.src wird mit einer Inline-Grafik versehen, Beispiel in Perl

$self->{STASH}{data64} = sprintf("data:image/png;base64,%s", encode_base64($hunt->{body}));

und das in den auszuliefernden DOM-String eingebaut (Achtung, das Datenvolumen wird viel größer!).

Horst

[Delbor]

Hi Hotti

.src zeigt auf eine Ressource, hinter der sich ein serverseitiger Prozess verbirgt, der das >Image mit dem passenden Content-Type (image/gif, image/png,...) ausliefert

Und dies Ressource könnte eben auch ein Blobstream sein, richtig?

Beachte bitte, dass solche Lösungen eine zusätzliche Serverlast erzeugen! Das kann mit einem sorgsamen Cache-Konzept zwar gemildert, jedoch nicht völlig aus der Welt geschafft werden.

Eine zusätzliche Serverlast? Was ist denn der Unterschied, wenn .src einerseits auf einen Dateipfad und andrerseits auf einen Stream zeigt? OK, der Stream belegt Arbeitsspeicher, und wenn die Seite mehrere Bilder benötigt, ergibt dies auch die entsprechende Grösse des belegten Speichers, bis die Seite ausgeliefert ist. Andrerseits  -  wenn ich die von meinem Hoster empfohlenen GGrössen beachte,,, sollte ich nicht grundsätzlich daneben liegen.

Eine Idee dazu hätte ich: Wenn an src statt eines Pfades auch ein Hexstring übergeben werden könnte, wäre genau dies die Lösung. Leider habe ich bisher nichts über alternative Zuweisungsmöglichkeiten gefunden.

Da war ich in meiner Schilderung etwas ungenau. Wenn ich in meiner IDE ein Bild zur Entwurfszeit einfüge, wird dieses als Hexstring in den Quellcode-Editor geschrieben  -  die eigentlichen Blobdaten bleiben unverändert.

Zwei der Möglichkeiten:

.src zeigt auf eine Ressource, hinter der sich ein serverseitiger Prozess verbirgt, der das Image mit dem passenden Content-Type (image/gif, image/png,...) ausliefert

Versteh ich das jetzt richtig: Wenn diese Ressource ein Hexstring wäre, müsste die Dateiendung als Hexstring angefügt werden?

.src wird mit einer Inline-Grafik versehen, Beispiel in Perl

$self->{STASH}{data64} = sprintf("data:image/png;base64,%s", encode_base64($hunt->{body}));

und das in den auszuliefernden DOM-String eingebaut (Achtung, das Datenvolumen wird viel größer!).

Diese 2. Möglichkeit tönt für mich irgendwie danach, dass je nach Anzahl der Bilder und der Grafikkarte auf dem Zielrechner meine 100kb-jpegs quälend langsam aufgebaut würden, neben wohl eher nicht notwendigem Traffic-Umfang. Das würde also gerade deshalb eher ausscheiden.

Gruss
Delbor

[Tom]

Hello,

Und dies Ressource könnte eben auch ein Blobstream sein, richtig?

Was ist denn ein "Blobstream"?

Ist das eine Strömung, an deren Ende es "Blobbbb" macht? *scnr*

Eine zusätzliche Serverlast? Was ist denn der Unterschied, wenn .src einerseits auf einen Dateipfad und andrerseits auf einen Stream zeigt?

Wie soll sowas gehen? Wer zeigt wie auf irgendwas? Meinset Du damit:

  
'<img src="target">'  
  

das erzeugt einen Request auf die aktuelle Base-URL und das Objekt "target". Insofern würde ich mir "zeigen auf" als Synonym gefallen lassen.

OK, der Stream belegt Arbeitsspeicher, und wenn die Seite mehrere Bilder benötigt, ergibt dies auch die entsprechende Grösse des belegten Speichers, bis die Seite ausgeliefert ist. Andrerseits  -  wenn ich die von meinem Hoster empfohlenen GGrössen beachte,,, sollte ich nicht grundsätzlich daneben liegen.

Alles Bla Bla. Jeder Request benötigt "Verbindungen" und "Buffers", egal, wie er abgewickelt wird.

Eine Idee dazu hätte ich: Wenn an src statt eines Pfades auch ein Hexstring übergeben werden könnte, wäre genau dies die Lösung. Leider habe ich bisher nichts über alternative Zuweisungsmöglichkeiten gefunden.

*hä?*

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[hotti]

hi,

.src zeigt auf eine Ressource, hinter der sich ein serverseitiger Prozess verbirgt, der das >Image mit dem passenden Content-Type (image/gif, image/png,...) ausliefert

Und dies Ressource könnte eben auch ein Blobstream sein, richtig?

Nenne es einfach Binary. Abstrakt ein Stream mit endlicher Länge. Blob, Stream, Binary, nunja, da unterscheidet die Fachwelt, da kannst Du Dich aber auch selbst einlesen ;)

Eine zusätzliche Serverlast? Was ist denn der Unterschied, wenn .src einerseits auf einen Dateipfad und andrerseits auf einen Stream zeigt?

Der Unterschied ist der, dass eine Datei vom Webserver selbst ausgeliefert wird. Hierbei greifen auch 'normale' Cache-Mechanismen, auf die ChrisB bereits hingewiesen hat. Ein 'Stream' (besser: native Binary) jedoch, der muss serverseitig ersteinmal erzeugt werden, das erfordert also einen zusätzlichen Prozess (und das Caching braucht eine proprietäre Lösung).

Da war ich in meiner Schilderung etwas ungenau. Wenn ich in meiner IDE ein Bild zur Entwurfszeit einfüge, wird dieses als Hexstring in den Quellcode-Editor geschrieben  -  die eigentlichen Blobdaten bleiben unverändert.

Ok. Das .src-Attribut erlaubt nur sowas:
   src="/path/webressource"
   src="data:image/png;base64,%s" // in %s ein Base64-String
   src="blob:cf1c52fc-d0ae-43bb-a6c9-d886bdc3d902" // browserinterne Referenz auf eine Binary

Und: Zwischen den "", also der Wert zum Attribut .src ist IMMER ASCII!!!

Ergo: Es funktioniert nicht, eine Binary einfach zwischen zwei "" zu setzen, das Warum einfach erklärt: Eine Binary enthält Oktetten aller Wertigkeiten (0..255, 0x0..0xFF), was im DOM nicht aktzeptiert wird. Ebesowenig kannst Du eine Binary in einem Texteditor bearbeiten, der wird stets versuchen, die Oktetten als Textzeichen darzustellen, was spätestens beim Speichern die Binary zerstört.

Versteh ich das jetzt richtig: Wenn diese Ressource ein Hexstring wäre, müsste die Dateiendung als Hexstring angefügt werden?

Nein, löse Dich mal vom Gedanken einer Dateiendung. Mit

img src="/path/webressource"

verweist das src-Attribut auf eine Webressource, in der Response wird die Binary für ein Image erwartet und normalerweise kümmert sich der Webserver darum, ebendiese Bild-Binärdaten selbst auszuliefern, indem der Webserver das Image selbst aus dem Dateisystem liest und unzerknittert in die Response schiebt.

Horst

[Tom]

Hello,

Der Unterschied ist der, dass eine Datei vom Webserver selbst ausgeliefert wird.

Bla-Bla-Bla

Wie wird denn diese Response initiiert?

Bitte ganz genau!

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[hotti]

Bla-Bla-Bla

Wie wird denn diese Response initiiert?

Bitte ganz genau!

Durch einen Request ;)

[T-Rex]

.src zeigt auf eine Ressource, hinter der sich ein serverseitiger Prozess verbirgt, der das Image mit dem passenden Content-Type (image/gif, image/png,...) ausliefert

Sorry Hotti, aber das ist eine immens schlechte Idee. Bei einem Projekt hatten wir genau das. Die Bilder wurden im Vergleich zur "normalen - such nach einer Bilddatei" Lösung sehr langsam geladen. Zudem umgeht man hier wieder alle automatischen Browser Caching verfahren.

Wir haben unser verfahren dann optimiert.
Es wird ein Bild angefragt z.B. bild.jpg. In der htaccess gibt es eine Umleitung auf ein Script sofern diese Datei nicht existiert (das wäre dein Weg). Dieses Script macht alles was nötig ist um das Bild zu erstellen. Dann wird es als bild.jpg in dem gewünschten Ordner abgespeichert. Beim nächsten Aufruf ist die Datei vorhanden.

Das geniale an der Lösung ist, dass man die Bilder nachträglich verändern kann. Liegt das Bild z.B. im Unterordner "wasserzeichen" werden Wasserzeichen eingebaut. Das kann auch nachträglich geschehen. Einfach Wasserzeichen Generierung aktivieren, alle Bilder löschen und bei "normalen" aufrufen der Webseite erstellen lassen. Der erste Aufruf der Bilder ist zwar immer noch relativ lang, da die Dateien dann aber im normalen Server Verzeichnis existieren geht es beim zweiten Aufruf sehr viel schneller.
Oder bei einem Relaunch. Die Bilder im Ordner Avatar werden im Zuge des Relaunch 10 Pixel größer. Script anpassen, Bilder löschen.

Für den Topic Ersteller wäre dies sowieso eine optimale Lösung. Die Bilder werden bei Datenbank Backups mitgespeichert und trotzdem sind normale Bilddateien für caching Mechanismen vorhanden.

Gruß
Genialer
T-Rex

[ChrisB]

Hi,

Mein Programm wird in der Lage sein, einzelne Textbausteine der Webseite auszuwechseln/individuell einzufügen. Zum Beispiel dass CSS-Sheet: Die Dateiangabe im HTML-Dokument wird es nicht mehr geben. Stattdessen wird das CSS aus einer Datenbank gelesen und vom Programm an der richtigen Stelle als String eingefügt.

Du magst also kein Caching?

Eine Idee dazu hätte ich: Wenn an src statt eines Pfades auch ein Hexstring übergeben werden könnte, wäre genau dies die Lösung.

Stichwort: Data URI.

In Bezug auf Caching natürlich analog blödsinnig zum „inlinen“ des Stylesheets, s.o.

MfG ChrisB

[Delbor]

Hi ChrisB

In Bezug auf Caching natürlich analog blödsinnig zum „inlinen“ des Stylesheets, s.o.

Aktuell gehts ja erstmal um die einzubindenden Bilder. Bei einem Desktopprogramm würde ich diese per Stream einer Imagekomponente zuweisen, was so aber in HTML nicht geht, bzw. ich weiss nicht, was alles möglich ist.

Aber dein Hinweis auf Caching bringt mich auf eine Idee: Da fast alle Seiten gleich Designed sind, brauch ich eigentlich die benötigten CSS-Dateien nicht jedesmal neu einzubinden (von spezifischen Fällen abgesehen(Die 'aktuelle Seite' im Navigationsmenue zb), und auch die Seite selbst kann längere Zeit auf dem Client verbleiben, da sich zwischen den meisten einzelnen Seiten nur die Inhalte unterscheiden.

Gruss
Delbor

[ChrisB]

Hi,

In Bezug auf Caching natürlich analog blödsinnig zum „inlinen“ des Stylesheets, s.o.

Aktuell gehts ja erstmal um die einzubindenden Bilder.

Und die sind nicht cache-wert?

Bei einem Desktopprogramm würde ich diese per Stream einer Imagekomponente zuweisen, was so aber in HTML nicht geht, bzw. ich weiss nicht, was alles möglich ist.

In einer Website würde ich das ganz clever™ machen: Sie vom Webserver aus dem *Dateisystem* ausliefern lassen! Der kümmert sich dann um alles, inklusive Caching.

MfG ChrisB

[Tom]

Hello,

In einer Website würde ich das ganz clever™ machen: Sie vom Webserver aus dem *Dateisystem* ausliefern lassen! Der kümmert sich dann um alles, inklusive Caching.

Das Dateisystem liefert hoffentlich auf einem Webserver gar nix selbstständig aus. Da könnten wir doch gleich den Obamaschlüssel an jedermann geben!

Du schriebst aber vorichtigerweise "aus dem *Dateisystem*"

Das deutet darauf hin, dass Du nicht genau weißt, wie das gehen soll, oder aber sehr genau weißt, dass das ganz schön aufwändig ist.

Und da ich jetzt nicht weiß, wie Du das "automatische Verhalten des Webservers (Caching-Anweisungen)" unter Beachtung von zu berücksichtigenden Zugriffsrechten auf die Files initiieren willst, bin ich seeeehr neugierig, hier weiter mitzulesen :-P

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[ChrisB]

Hi,

Das deutet darauf hin, dass Du nicht genau weißt, wie das gehen soll, oder aber sehr genau weißt, dass das ganz schön aufwändig ist.

Was ist daran aufwendig, einen Webserver statische Dateien aus dem Dateisystem ausliefern zu lassen – von der VirtualHost-Konfiguration (die es in jedem Fall braucht) mal abgesehen?

Und da ich jetzt nicht weiß, wie Du das "automatische Verhalten des Webservers (Caching-Anweisungen)" unter Beachtung von zu berücksichtigenden Zugriffsrechten auf die Files initiieren willst

Von Zugriffsrechten auf Benutzerebene war bisher keine Rede.

MfG ChrisB

[Tom]

Hello,

Das deutet darauf hin, dass Du nicht genau weißt, wie das gehen soll, oder aber sehr genau weißt, dass das ganz schön aufwändig ist.

Was ist daran aufwendig, einen Webserver statische Dateien aus dem Dateisystem ausliefern zu lassen – von der VirtualHost-Konfiguration (die es in jedem Fall braucht) mal abgesehen?

Dass Du hier nicht zeigst, wie es geht?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[ChrisB]

Hi,

Das deutet darauf hin, dass Du nicht genau weißt, wie das gehen soll, oder aber sehr genau weißt, dass das ganz schön aufwändig ist.

Was ist daran aufwendig, einen Webserver statische Dateien aus dem Dateisystem ausliefern zu lassen – von der VirtualHost-Konfiguration (die es in jedem Fall braucht) mal abgesehen?

Dass Du hier nicht zeigst, wie es geht?

Wozu sollte ich das zeigen?

Der TO hat bereits einen Webserver laufen bzw. vorkonfigurierten Webspace – und dass von dort statische Dateien, die inerhalb des öffentlichen Web-Verzeichnisses platziert sind, ausgeliefert werden können, ist doch wohl auszugehen.

MfG ChrisB