nicht angemeldet
SSI in Apache und IIS
hallo Forum ;-)
Ich experimentiere grade ein bißchen mit SSI herum und muß dazu wohl doch die eine oder andre Nachfrage stellen. In SELFHTML gibts eine sehr kurz gefaßte Erläuterung dazu, aber die Übersicht ist leider nicht nur kurz, sondern auch unvollständig.
Erst einmal: ich habe zum Durchtesten mit WinXP meinen lokalen Apache 2.0.44 benutzt - selbstverständlich "kann" der SSI. Um es mir online anzuschauen, benutze ich einen Provider, der den IIS 5 einsetzt - auch da sind SSI zulässig. Die Dokumentation, die ich am häufigsten konsultiert habe, ist natürlich die Apache-Dokumentation, für den IIS habe ich noch nix gefunden, auch in der MSDN nicht (hallo Bio ;-)), möglicherweise hab ich in der MSDN aber auch nicht alles durchsucht. Daher weiß ich nicht genau, was der IIS _prinzipiell_ bereitstellt. Google liefert mir schlicht zuviele Adressen, um alles tatsächlich durchstöbern zu können ... Hat jemand irgendwo eine möglichst tabellarisch aufgearbeitete Gegenüberstellung, welche "Befehle" für SSI im Apache und im IIS eingesetzt werden können (ungefähr in der Art, wie es in http://selfhtml.teamone.de/cgiperl/intro/ssi.htm#uebersicht zu finden ist)?
So, und jetzt drei Nachfragen:
erstens:
Ich habe eine Test-Konstruktion, bei der in einem (X)HTML-file (das selbstverständlich *.shtml heißt) links einen schmalen Layer (DIV) mit der Navigation liegt, und rechts aus einer längeren Liste mit exakt gleich CSS-positionierten DIVS jeweils einer sichtbar gemacht wird. Das funktioniert ganz gut, ist ja auch nur 'ne "Fingerübung". Jetzt bestehen meine unsichtbaren/sichtbaren DIV's aber im Prinzip nur aus sowas:
<div id="name">
<!--#include file="datei.htm" -->
</div>
Und da gehts dann los. Mein Apache weigert sich, ein HTML-Dokument einzubinden, obwohl ich exakt so verfahren bin, wie in der Apache-Dokumentation beschrieben. Nenne ich das file aber statt "datei.htm" mal probeweise "datei.txt", macht er es. Der IIS meines Providers erklärt sich solidarisch und verfährt ebenso. Hat jemand eine Erklärung dafür? Ich kann und will meine HTML-Dokumente natürlich nicht mit einer "falschen" Extension versehen, weil sie auch einzeln, also als eigenständige Dokumente, aufrufbar bleiben sollen ...
Und dann: Meine HTML-Dokumente haben alle eine DOCTYPE-Angabe, zwei meta-tags, einen Header-Bereich usw. Das heißt, ich habe unter Umständen mehrere Dutzend (immer dieselben) DOCTYPE-Angaben, die bereits auf dem Server in einer "großen" Datei zusammengeklebt werden und auch so beim Browser ankommen, ebenso habe ich mehrere dutzendmal
<html>
<head>
...
</head>
<body>
...
</body>
</html>
mozilla und Internet Explorer machen das zwar mit, und zeigen es mir bei rechtem Mausklick auch brav als Quelltext an (Opera hab ich im Moment nicht installiert), aber schön ist das halt nicht, und obs valide wäre, mochte ich gar nicht erst testen. Natürlich könnte ich das alles rausstreichen, und als einzigen "Content" meiner HTML-Dokumente nur noch das drinstehen lassen, was normalerweise zwischen <body> und </body> steht - aber dann sind die Einzelseiten nicht mehr valide und ich kann mich nicht mehr leiden. Das einzige, was mir bisher eingefallen ist, wäre, sämtliche HTML-Dokumente vor dem Includieren erst durch ein Perl-Script aufrufen zu lassen, das die "überflüssigen" Auszeichnungen entfernt. Hat jemand ne bessere Idee?
zweitens:
Jetzt möchte ich aber in (mindestens) eins meiner DIV's ein XML-Dokument reinschubsen. Geht zwar prinzipiell auch, aber da gibts Unterscheide bei den Servern. Mein Apache möchte es gerne in der Form
<!--#include virtual="daten.xml" -->
haben, dann gehts prima. Aber der IIS bei meinem Provider zeigt da gar nix an, der möchte zwingend
<!--#include file="daten.xml" -->
Zwar kann ich beide Angaben in meine SHTML reinschreiben, für die Browserdarstellung ergibt das keinen Unterschied, aber für den "Quelltext" in meinem Browsercache ergibt das eine Verdopplung der Größe. Bleibt mir wirklich nix andres übrig als mit einer "if"-Abfrage über "SERVER_SOFTWARE" den grade aktiven Server zu ermitteln?
Und dann ergibt sich ein ähnliches Problem für die "Kopfdaten" wie bei den HTML-Dokumenten. Ich habe in meiner XML drinstehen:
<?xml version='1.0' encoding="ISO-8859-1"?>
<!DOCTYPE schnauss SYSTEM "style/test.dtd">
<?xml-stylesheet type="text/xsl" href="style/test.xsl"?>
was normalerweise gut funktioniert, wenn ich meine XML als Einzeldatei über den Server aufrufe. Binde ich sie aber mit SSI ein, bekommt der Browser das nicht mehr als Dateikopf angezeigt, sondern erst nach viel, viel anderem HTML-Code, es steht also nicht mehr im Dateikopf (da steht eine andere DOCTYPE-Angabe) und dann scheint es ihm egal zu sein, meine DTD und meine XSL werden nicht mehr vollständig berücksichtigt (Details erspare ich mir im Moment, das wird ein anderer Thread, weil ich dazu noch mehr "XML-Nachfragen" habe)
drittens:
Macht das überhaupt Sinn, aich so eine "SSI-Konstruktion" auszudenken? Folgendes Hemmnis sehe ich: zwar sind sämtliche Einzeldateien hübsch klein, auch die HTML-Dokumente und meine XML sind höchstens 40 kB groß. Aber wenn ich jetzt nur 30 Stück davon includiere, werden sie ja alle bereits auf dem Server zusammengeklebt und im Browser dargestellt, was dazu führt, daß die Anzeige des "Quelltextes" der im Browser angezeigten Gesamtdatei schnell mal eine Größe von 1 MB und mehr erreichen kann. Das ist lokal natürlich kein Problem, aber online mag ich mir ja nicht erst 1 MB runtersziehen müssen, selbst mit meiner DSL-Verbindung nicht. Und bei einem "Projekt", in dem es dann ja in den HTML-Dokumenten auch noch diverse Grafiken geben kann und in dem ich mit 30 Einzeldokumenten bei weitem nicht auskomme, kann mich das doch bedenklich xtimmen. Meine bisherigen online-Testläufe hab ich zwar nur mit 20 HTML-Dokumenten gemacht, und erstaunlicherweise war die Browseranzeige nahezu sofort da. Trotzdem bin ich da mißtrauisch.
Es macht nicht viel Sinn, die URL zu nennen, weil ihr ja damit die "SSI-Konstruktion" nicht zu sehen bekommt. Ich hoffe, ich hab mein augenblickliches "Problem" einigermaßen verständlich dargestellt.
Grüße aus Berlin
Christoph S.
-
Hallo Christoph,
Daher weiß ich nicht genau, was der IIS _prinzipiell_ bereitstellt.
ich würde als Arbeitshypothese annehmen, daß er SSI kann, nicht aber XSSI.
<div id="name">
<!--#include file="datei.htm" -->
</div>Hoppla. Du willst ein vollständiges HTML-Dokument (mit <html> usw.) in ein <div> einbinden?
Welcher Dokumenttyp soll Deiner Meinung nach dabei herauskommen?Außerdem ist "include file" laut Apache-Dokumentation deprecated.
Und da gehts dann los. Mein Apache weigert sich, ein HTML-Dokument einzubinden, obwohl ich exakt so verfahren bin, wie in der Apache-Dokumentation beschrieben.
Was bedeutet das im Klartext? "Geht nicht" geht nicht.
Fehlerbeschreibung, bitte - inklusive eventueller Fehlermeldungen aus dem error_log.Ich kann und will meine HTML-Dokumente natürlich nicht mit einer "falschen" Extension versehen, weil sie auch einzeln, also als eigenständige Dokumente, aufrufbar bleiben sollen ...
Genau das bezweifele ich eben - daß Du ein vollständiges HTML-Dokument in ein <div>-Tag eines HTML-Dokuments includen darfst und als Ergebnis wieder ein korrektes HTML-Dokument bekommst.
Du hast gar keine andere Wahl, als einen Schnipsel zu includen - und den kannst Du dann problemlos mit einer anderen Endung versehen.
Willst Du diesen Schnipsel "alleine" auch verwenden, dann brauchst Du eine zweite SSI-Datei, die eine dafür angepaßte Umgebung erzeugt und ebenfalls diesen Schnipsel includet.Ich mache das auf meiner Homepage schon lange so - damit realisiere ich die parallele Navigation mit und ohne Frames: Das, was in der Frames-Variante im Arbeits-Frame als Startseite (die selbst wiederum ein SSI-Dokument mit minimalem eigenen Inhalt ist) geladen wird, ist in der frameslosen Variante in den <body> des Frameset-Dokuments eingebettet.
Vergleiche
http://www.schroepl.net/frameset.shtml?unten
mit http://www.schroepl.net/noframes.shtml;
der gemeinsame Include-Schnipsel dazu ist
http://www.schroepl.net/_updates.inc.Und dann: Meine HTML-Dokumente haben alle eine DOCTYPE-Angabe, zwei meta-tags, einen Header-Bereich usw. Das heißt, ich habe unter Umständen mehrere Dutzend (immer dieselben) DOCTYPE-Angaben, die bereits auf dem Server in einer "großen" Datei zusammengeklebt werden und auch so beim Browser ankommen
Eben - genau das ist das Problem.
Was Du willst, das geht einfach nicht (so). Die HTML-Köpfe müssen raus aus den Include-Schnipseln - folglich können letztere keine vollständigen HTML-Dokumente sein.Das einzige, was mir bisher eingefallen ist, wäre, sämtliche HTML-Dokumente vor dem Includieren erst durch ein Perl-Script aufrufen zu lassen, das die "überflüssigen" Auszeichnungen entfernt.
Das ist doch viel aufwändiger, als zwei SSI-Dateien zu halten.
Mein Apache möchte es gerne in der Form
<!--#include virtual="daten.xml" -->
haben, dann gehts prima. Aber der IIS bei meinem Provider zeigt da gar nix an, der möchte zwingend
<!--#include file="daten.xml" -->Willkommen in der Welt der proprietären Webserver. Es hat schon seinen Grund, warum man zum Testen exakt denselben Webserver lokal verwenden muß und nicht irgendeinen.
Was glaubst Du, was mir alles um die Ohren fliegen würde, wenn meine Seiten auf einem IIS lägen, der kein .htaccess kann? Weia ...Bleibt mir wirklich nix andres übrig als mit einer "if"-Abfrage über "SERVER_SOFTWARE" den grade aktiven Server zu ermitteln?
Verwende einfach denselben Webserver, dann hast Du Dein Problem nicht.
Oder löse die SSIs client-seitig auf (per Programm, vor dem Hochladen), dann hast Du auf dem Server nur noch statisches HTML. So mache ich das bei einigen meiner Seiten (u. a. weil gzip_cnc statische Seiten komprimieren kann, dynamische aber nicht).
Macht das überhaupt Sinn, aich so eine "SSI-Konstruktion" auszudenken?
Entsteht dabei ein Dokument, das Dein Besucher als sinnvoll ansehen würde?
Ich habe ein Dokument mit 309 KB (eine komplette Release-Historie einer 15 Jahre alten Software) auf meiner Domain liegen - weil der Besucher in diesem Dokumenten mit Cntrl-F suchen könnte, wenn er wollte (z. B. um herauszufinden, in welchem Release ein bestimmtes Feature eingebaut wurde). Es wäre viel umständlicher für den Benutzer, etwas zu finden, wenn ich dieses Dokument in viele Dateien zerlegen würde - man könnte nicht mal besser navigieren, aber deutlich schlechter suchen.
Aber wenn ich jetzt nur 30 Stück davon includiere, werden sie ja alle bereits auf dem Server zusammengeklebt und im Browser dargestellt, was dazu führt, daß die Anzeige des "Quelltextes" der im Browser angezeigten Gesamtdatei schnell mal eine Größe von 1 MB und mehr erreichen kann.
Und? Kann der Anwender dieses Dokument brauchen oder nicht?
Die Forums-Hauptdatei ist ja auch relativ groß - aber niemand käme auf die Idee, sie aus Performance-Gründen zu zerteilen, weil das bekanntlich die Usability verschlechtern würde.Das ist lokal natürlich kein Problem, aber online mag ich mir ja nicht erst 1 MB runtersiehen müssen, selbst mit meiner DSL-Verbindung nicht.
Je generischer Dein HTML-Code ist, um so besser wäre der Komprimierungsfaktor via gzip:
xxx.xxx.xxx.xxx - - [30/Jan/2003:19:26:14 +0100] "GET /kurslisten/inhalt/idx2.pl?idx=16966&xslanguage=en HTTP/1.1" 200 4744 "-" "Mozilla/5.0 (rv:1.3a)" "SHARK=CLIENT%3DFXSENG%3B+USER%3Dms%3B+CONN%3D11%3B" "-" "gzip" DECHUNK:OK 99962 -> 4744 = 96 Prozent
Und ja, das _ist_ sehr schlechter HTML-Code - weil es in Netscape 4 funktionieren muß. :-(
Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.-
hi Michael,
<!-- ohje, jetzt ist ein langer Antworttext, den ich vor knapp einer Stunde geschrieben hatte, irgendwo verschütt gegangen :-( -->
Hoppla. Du willst ein vollständiges HTML-Dokument (mit <html> usw.) in ein <div> einbinden?
Schön wärs halt. Siehe weiter unten.
Außerdem ist "include file" laut Apache-Dokumentation deprecated.
Weiß ich. Funktioniert allerdings trotzdem, wie alles, was "deprecated" ist. Was mich allerdings in keiner Weise legitimiert, so zu verfahren
Mein Apache weigert sich, ein HTML-Dokument einzubinden
Was bedeutet das im Klartext? "Geht nicht" geht nicht.Ja doch ... ;-)
Fehlerbeschreibung, bitte
Wenn ich eine liefern könnte, wäre ich heilfroh. Es gibt keine. Es passiert einfach wirklich _nichts_
inklusive eventueller Fehlermeldungen aus dem error_log.
Dasselbe. Es gibt in de logs nichts. aber im Browser passiert auch nichts. Dabei habe ich meine logs schon so "verbose" wie nur irgend möglich eingestellt
Genau das bezweifele ich eben - daß Du ein vollständiges HTML-Dokument in ein <div>-Tag eines HTML-Dokuments includen darfst
Ja, das ist einer der Hintergründe meiner Nachfrage. Ich habe nirgends gefunden, daß ich das nicht darf. Also bin ich zum Durchspielen einfach davon ausgegangen, daß ich alles, was nicht verboten oder "deprecated" ist, auch machen kann. Und bin erstmal auf die Nase gefallen.
Was Du willst, das geht einfach nicht (so). Die HTML-Köpfe müssen raus aus den Include-Schnipseln - folglich können letztere keine vollständigen HTML-Dokumente sein.
Genau das ist letzten Endes mein Problem. Wenn ich meine HTML-Dokumente de facto "verdoppeln" muß, geht das relativ rasch zu Lasten des vorhandenen Webspace.
Mein Apache möchte es gerne in der Form
<!--#include virtual="daten.xml" -->
haben, dann gehts prima. Aber der IIS bei meinem Provider zeigt da gar nix an, der möchte zwingend
<!--#include file="daten.xml" -->
Willkommen in der Welt der proprietären Webserver
Verwende einfach denselben Webserver, dann hast Du Dein Problem nicht.Ich habe den IIS derzeit nicht lokal zur Verfügung, aber ich habe auch ganz bewußt einen "IIS-Provider" (glücklicherweise gibts nicht viele davon) gesucht, um den Vergleich zu erhalten. Ob ich den IIS lokal oder online teste, ist auch eigentlich egal.
Macht das überhaupt Sinn, aich so eine "SSI-Konstruktion" auszudenken?
Entsteht dabei ein Dokument, das Dein Besucher als sinnvoll ansehen würde?Es soll ein Dokument entstehen, das der Besucher sogar anfordert, also muß er es wohl für sinnvoll halten.
Und? Kann der Anwender dieses Dokument brauchen oder nicht?
siehe oben ... wenn ein Besucher überhaupt dorthin geht, hat er eine ganz bestimmte, zielgerichtete und vorher erzeugte Erwartung. Also kann er es auch brauchen.
Die Forums-Hauptdatei ist ja auch relativ groß - aber niemand käme auf die Idee, sie aus Performance-Gründen zu zerteilen
Die Forumshauptdatei wird aber als wesentlich kleinerer Datenstrom übetragen. Ihre Größe ereicht sie erst wirklich im aufrufenden Browser
Grüße aus Berlin
Christoph S.
-
Hi Christoph,
Was Du willst, das geht einfach nicht (so). Die HTML-Köpfe müssen raus aus den Include-Schnipseln - folglich können letztere keine vollständigen HTML-Dokumente sein.
Genau das ist letzten Endes mein Problem. Wenn ich meine HTML-Dokumente de facto "verdoppeln" muß, geht das relativ rasch zu Lasten des vorhandenen Webspace.Du mußt aber nicht die vollständigen Dokumente verdoppeln - nur die "Hüllen".
Siehe mein Beispiel mit meinen Update-Meldungen - beide "Hüllen" sind sehr klein, während die eingebundene Datei wächst und (als einzige dieser drei) gewartet wird.
Die Forums-Hauptdatei ist ja auch relativ groß - aber niemand käme auf die Idee, sie aus Performance-Gründen zu zerteilen
Die Forumshauptdatei wird aber als wesentlich kleinerer Datenstrom übetragen. Ihre Größe ereicht sie erst wirklich im aufrufenden BrowserWenn ich das recht in Erinnerung habe, dann gibt es auch für den IIS einen Komprimierer (für statische Seiten wenigstens) ...
Und wenn nicht, kann der wenigstens Content Negotiation, so daß Du die komprimierte Version statisch auf dem Server vorhalten würdest (per Programm generiert, natürlich)?
Das klingt jedenfalls alles so, als wäre echt dynamisches SSI auf Deinem Server nicht der Königsweg. Ein Perl-Skript, welches mit LWP::Simple die SSI-Dokumente absaugt und als statisches HTML abspeichert (das Du dann komprimiert ausliefern könntest ...), habe ich im Einsatz ...
Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.-
hallo Michael,
Wenn ich meine HTML-Dokumente de facto "verdoppeln" muß
Du mußt aber nicht die vollständigen Dokumente verdoppeln - nur die "Hüllen".Nee. Gerade die "Hüllen" muß ich wegschmeißen (was soll ich mit 30 DOCTYPE-Angaben in einem HTML-file), und den "Content" behalten und unter beliebiger, aber vom Server handlebarer Extension abspeichern. Bei einem bereits 30 kB großen file Bedeutet das aber nahezu eine "Verdoppelung"
Wenn ich das recht in Erinnerung habe, dann gibt es auch für den IIS einen Komprimierer (für statische Seiten wenigstens)
Wär mir lieb, wenn du in deiner gewohnten Exaktheit das genauer aussagen könntest
Und wenn nicht, kann der wenigstens Content Negotiation, so daß Du die komprimierte Version statisch auf dem Server vorhalten würdest (per Programm generiert, natürlich)?
Weiß ich nicht, müßte ich durchprobieren
Ein Perl-Skript [...] habe ich im Einsatz
Dann wirf doch bitte schnell mal rüber, vielleicht kann ichs für mein Problem einbauen oder bedarfsgerecht "ummodeln"
Grüße aus Berlin
Christoph S.
-
Hallo Christoph,
Wenn ich meine HTML-Dokumente de facto "verdoppeln" muß
Du mußt aber nicht die vollständigen Dokumente verdoppeln - nur die "Hüllen".
Nee. Gerade die "Hüllen" muß ich wegschmeißen (was soll ich mit 30 DOCTYPE-Angaben in einem HTML-file), und den "Content" behalten und unter beliebiger, aber vom Server handlebarer Extension abspeichern.Ich glaube Michael meinte, dass wenn du die einzelen Dateien auch als vollständige Einzeldateien brauchst erstellst du für diese die Hülle (dort wo sie als einzelen vollständige Dateien gebraucht werden) und dann bindest du den eingeltichen Inhalt, den du als snipplet abgelegt hat, sowohl in diese als auch in der große Datei ein.
Was dein anderes Problem angeht, wenn du der Sekretärin schon <title> und <text> beibringen kannst, kannst du ihr ja stattdessen <h1> und <div> beibringen, dann hast du bereits deinen snipplet und du kannst es einbinden, ohne dir gedanken über XML machen zu müssen.
Dazu fällt mir eine Testalternative ein, wenn es unbedingt XML sein muss: habe aber nicht ausprobiert: mit SSI eine PHP-Datei einbinden die die XML-XSL-Transformation durchführt. Ob du das aber nicht mit einem Perl-Script einfacher haben würdest?
Grüße
Thomas-
morgens,
Ich glaube Michael meinte, dass wenn du die einzelen Dateien auch als vollständige Einzeldateien brauchst erstellst du für diese die Hülle (dort wo sie als einzelen vollständige Dateien gebraucht werden) und dann bindest du den eingeltichen Inhalt, den du als snipplet abgelegt hat, sowohl in diese als auch in der große Datei ein.
Hm. Wenn er das so gemeint hat, hab ich das nicht gleich so gelesen. Aber du hast recht. Probier ich am Wochenende mal durch - ups, nee, geht nicht, da machen wir ja nen mini-SELFHTML-Treffen hier in Bärlin ;-)
Was dein anderes Problem angeht, wenn du der Sekretärin schon <title> und <text> beibringen kannst, kannst du ihr ja stattdessen <h1> und <div> beibringen
Naja, es ist leider bissel mehr. Was die Sekretärin angeht, ist es tatsächlich "nur das", was mich angeht, sind es noch ein paar Sächelchen mehr, und da möchte ich dann halt gerne das "Prinzip" lösen. Denn es ist bei meiner XML genauso, wie mit "vollständigen" HTML-Dateien: ich muß erstmal im Header sagen, daß es XML sein soll. Und wenn ich das per SSI in meine "große" Datei reinschubse, kriege ich im Endeffekt - sehr stark verkürzt - sowas:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>...</head>
<body>
... viel Inhalt und viele includes ...<?xml version='1.0' encoding="ISO-8859-1"?>
<!DOCTYPE schnauss SYSTEM "style/meine.dtd">
<?xml-stylesheet type="text/xsl" href="meine.xsl"?>
<meineseite>
<title>Seite mit SSI</title>
<text>hallo Welt ;-)</text>/body>
</html>
Und das gefällt mir gar nicht
Dazu fällt mir eine Testalternative ein, wenn es unbedingt XML sein muss: habe aber nicht ausprobiert: mit SSI eine PHP-Datei einbinden die die XML-XSL-Transformation durchführt. Ob du das aber nicht mit einem Perl-Script einfacher haben würdest?
Weiß ich (noch) nicht. Der Vorschlag wirkt erstmal so ganz vernünftig, muß ich auch erstmal durchprüfen. Allerdsings wollte ich eben gerne möglichst ohne "Zusätze" wie PERL oder PHP auskommen.
Danke erstmal für die Hinweise. Man hat ja nach ner Weile immer die berühmten "Tomaten vor den Augen", da bin ich keine Ausnahme. Jetzt sehe ich erstmal ein paar Wege, die ich noch gehen müßte. Und wenns dann nicht klappt, eröffne ich halt nen neuen Thread - in einer oder in zwei oder in vielen Wochen ;-)
Grüße aus Berlin
Christoph S.
-
Hi Christoph,
Ich glaube Michael meinte, dass wenn du die einzelen Dateien auch als vollständige Einzeldateien brauchst erstellst du für diese die Hülle (dort wo sie als einzelen vollständige Dateien gebraucht werden) und dann bindest du den eingeltichen Inhalt, den du als snipplet abgelegt hat, sowohl in diese als auch in der große Datei ein.
ja, das meinte er. ;-)
Und wenn ich das per SSI in meine "große" Datei reinschubse, kriege ich im Endeffekt - sehr stark verkürzt - sowas:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>...</head>
<body>
... viel Inhalt und viele includes ...<?xml version='1.0' encoding="ISO-8859-1"?>
<!DOCTYPE schnauss SYSTEM "style/meine.dtd">
<?xml-stylesheet type="text/xsl" href="meine.xsl"?>
<meineseite>
<title>Seite mit SSI</title>
<text>hallo Welt ;-)</text>/body>
</html>Und das gefällt mir gar nicht
Mir auch nicht. Wenn Du in der "Hülle" definierst, daß das Gesamt-Dokument HTML sein soll, dann müssen die Schnipsel sich daran halten. Die Schnipsel dürfen natürlich keine vollständigen HTML-Dokumente sein - aber XML darf dann schon gleich gar nicht vorkommen.
Statt dessen müssen die bereits nach HTML konvertierten Schnipsel eingebunden werden.
Dies über den Aufruf eines Konverters on the fly zu lösen, macht die Sache natürlich ressourcenfressender ... ich würde da lieber das Äquivalent eines "make" verwenden, also nach jedem Upload von XML-Dokumenten den gesamten Datenbestand auf Konsistenz prüfen und allfällige Konvertierungen zu diesem Zeitpunkt einmalig durchführen. (So ähnlich macht das die Apache Group in dieser Situation auch.)Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.-
hi,
ich würde da lieber das Äquivalent eines "make" verwenden, also nach jedem Upload von XML-Dokumenten den gesamten Datenbestand auf Konsistenz prüfen und allfällige Konvertierungen zu diesem Zeitpunkt einmalig durchführen. (So ähnlich macht das die Apache Group in dieser Situation auch.)
Ich weiß ungefähr, wie die Jungs das machen. Und ich würde das wohl auch mit bissel Anstrengung hinkriegen, wenn der Server ein UNIX-Server wäre und das Ganze über den Apache ginge - kann ich bei mir zuhause mit FreeBSD durchspielen.
Ich muß aber berücksichtigen, daß das ganze "Projekt", an dem ich da herumdenke, letzten Endes auf einem WinXP-Server mit IIS 5 landen wird. Zwar gibts auch für Windows ein "make", das hat der Provider aber nicht drauf, und wie ich das mit Client-Zugriff hinkriegen soll, ist mir rätselhaft. Ich konnte bisher dem (künftigen) Provider nicht erklären, was ich überhaupt machen möchte.Grüße aus Berlin
Christoph S.
-
Hi Christoph,
Zwar gibts auch für Windows ein "make", das hat der Provider aber nicht drauf, und wie ich das mit Client-Zugriff hinkriegen soll, ist mir rätselhaft. Ich konnte bisher dem (künftigen) Provider nicht erklären, was ich überhaupt machen möchte.
für Deinen Spezialfall brauchst Du aber viel weniger als ein richtiges "make" mit dessen komplexer Regelsprache.
Du brauchst nur einen rekursiven Verzeichnistraversierer, der nach Pärchen von Dateien mit verwandten Namen sucht und dann mit einem system()-Call aus der einen die andere herstellt. 100 Zeilen Perl, schätze ich mal.Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.-
n'abends,
Du brauchst nur einen rekursiven Verzeichnistraversierer, der nach Pärchen von Dateien mit verwandten Namen sucht und dann mit einem system()-Call aus der einen die andere herstellt. 100 Zeilen Perl, schätze ich mal.
Das heißt im Endeffekt ja dann doch, daß ich PERL "zwischenschalten" muß. Hätte ich gerne vermieden
Grüße aus Berlin
Christoph S.
-
Hi Christoph,
100 Zeilen Perl, schätze ich mal.
Das heißt im Endeffekt ja dann doch, daß ich PERL "zwischenschalten" muß.Keineswegs. (s/Perl/3GL-Sprache Deiner Wahl/)
Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.-
morgens,
ähm, warte mal, da versteh ich jetzt was nicht. Erst hast du gesagt:
100 Zeilen Perl, schätze ich mal.
Das verstehe ich noch, und würde es wahrscheinlich mit bissel Nachdenken auch hinkriegen (wenn es dabei Fehler gibt, kann ich ja hier im Forum nachfragen). Aber auf meinen Stoßseufzer
Das heißt im Endeffekt ja dann doch, daß ich PERL "zwischenschalten" muß.
antwortest du:
Keineswegs. (s/Perl/3GL-Sprache Deiner Wahl/)
Entschuldige, aber da macht meine Logik (noch) nicht mit. Und übrigens: "SQL-Sprache meiner Wahl" bedeutet zur Zeit als "default" natürlich mySQL. Das geht, das macht/kann auch der Provider mit seinem WinXP-Server.
Aber den ganzen Krempel dynamisch in eine mySQL-Datenbank zu packen, ist ein völlig anderes Herangehen. Es hat was für sich, ganz ohne Frage - oder hab ich dich jetzt nicht richtig verstanden?
Grüße aus Berlin
Christoph S.
-
-
-
-
-
-
-
-
Hi Christoph,
Wenn ich das recht in Erinnerung habe, dann gibt es auch für den IIS einen Komprimierer (für statische Seiten wenigstens)
Wär mir lieb, wenn du in deiner gewohnten ExaktheitIiiih - Honig klebt. ;-)
das genauer aussagen könntest
Google fand sofort (1. Seite) das hier:
http://www.microsoft.com/technet/prodtechnol/iis/maintain/featusability/httpcomp.asp
(Hm, das Verfahren merke ich mir jetzt: M$-Links in Opera mit abgeschaltetem JavaScript in der Location-Zeile URL-kürzen, um den Auto-Framer dadurch abzuschalten - _solche_ URLs kann man hier problemlos verlinken ... :-)Ich hatte in Erinnerung, daß Google bei einer Suche nach "mod_gzip" rechts einen (offenbar gesponsorten) Link auf eine (kommerzelle) IIS-Lösung einblendet - was ebenfalls der Fall ist.
Ein Perl-Skript [...] habe ich im Einsatz
Dann wirf doch bitte schnell mal rüber, vielleicht kann ichs für mein Problem einbauen oder bedarfsgerecht "ummodeln"Ich traversiere das "."-Verzeichnis und mache LWP::Simple-Calls auf daraus berechnete URLs, die ich in Dateien mit abgeleitetem Namen (*.html statt *.shtml) abspeichere. Ganz einfach:
#!/usr/bin/perl
#################################################generate static HTML files from SSI files
#################################################
=====================================================================
use strict;
use LWP::Simple;=====================================================================
my $root_path = @ARGV[0];
my $root_url = @ARGV[1];=====================================================================
opendir (DIR, '.');
my @entries = readdir (DIR);
foreach my $this_entry (@entries)
{
# ---------------------------------------------------------
# generate a "*.html" file for each "*.shtml" there
if ($this_entry =~ /^([^_].*).shtml$/)
{
# --------------------------------------------------
# isolate resulting file name
my $file_truename = $1;
# --------------------------------------------------
my $new_path = "$root_path/$file_truename";
print "generating $new_path ...\n";
# --------------------------------------------------
# HTTP-GET the corresponding URL content
LWP::Simple::getstore ("$root_url/$file_truename.shtml", $new_path);
# --------------------------------------------------
}
# ---------------------------------------------------------
}=====================================================================
Vermutlich bräuchtest Du die Erweiterung, um Deinen kompletten Baum rekursiv abzuwandern ...
Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.-
morgens,
http://www.microsoft.com/technet/prodtechnol/iis/maintain/featusability/httpcomp.asp
Muß ich mir gründlicher durchlesen. Sieht allerdings leider auf den ersten flüchtigen Blick so aus, als ob das den _Server_ angeht. Da kann ich an die Software nicht ran. Infrage kommt ausschließlich eine clientseitige Lösung. Vielleicht stehts ja in den Teilen, die ich jetzt noch nicht richtig gelsen hab, drin.(Hm, das Verfahren merke ich mir jetzt: M$-Links in Opera [...]
Ich habe Opera zur Zeit nicht installiert. Und wenn ich mir die aktuelle Debatte im Forum zu Opera7 anschaue, bin ich nicht sicher, ob ich mir einen neuen Opera sofort installieren muß.
Ein Perl-Skript [...] habe ich im Einsatz
Dann wirf doch bitte schnell mal rüber
Ich traversiere das "."-Verzeichnis und mache LWP::Simple-Calls auf daraus berechnete URLs, die ich in Dateien mit abgeleitetem Namen (*.html statt *.shtml) abspeichere. Ganz einfachHm. Tatsächlich "ganz einfach"? Schaun mer mal ...
Grüße aus Berlin
Christoph S.
-
Hi Christoph,
http://www.microsoft.com/technet/prodtechnol/iis/maintain/featusability/httpcomp.asp
Muß ich mir gründlicher durchlesen. Sieht allerdings leider auf den ersten flüchtigen Blick so aus, als ob das den _Server_ angeht. Da kann ich an die Software nicht ran. Infrage kommt ausschließlich eine clientseitige Lösung._Jede_ Lösung, die zur komprimierten Übertragung führen soll, _muß_ sowohl auf dem Server komprimieren als auch auf dem Client dekomprimieren. Letzteres ist trivial (bei modernen Browsern), ersteres ist unvermeidlich. Auch gzip_cnc arbeitet ja auf dem Server - wenngleich nicht als Modul, sondern als CGI-Skript über die Apache-eigene Handler-Einbindungs-Schnittstelle.
Die Komprimierung muß nun mal erfolgen, bevor der Server das Zeug auf die Leitung kippt.(Hm, das Verfahren merke ich mir jetzt: M$-Links in Opera [...]
Ich habe Opera zur Zeit nicht installiert.Ich meinte nur deshalb Opera, weil ich dort am schnellsten JavaScript ein- und ausschalten kann (was ich ansonsten beruflich permanent brauche).
Und wenn ich mir die aktuelle Debatte im Forum zu Opera7 anschaue, bin ich nicht sicher, ob ich mir einen neuen Opera sofort installieren muß.
Mein Fazit: Ressourcen-Sau (35-40 MB), CSS deutlich verbessert, DHTML sehr träge (document.write von großen Dokumenten ist viiiiel langsamer als Mozilla), Surfen wie gewohnt sehr schnell.
Bei leistungsfähigem Rechner (RAM) ist seine Chance, ein Konkurrent für Mozilla zu werden, IMHO gestiegen.Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.-
hallo Michael,
_Jede_ Lösung, die zur komprimierten Übertragung führen soll, _muß_ sowohl auf dem Server komprimieren als auch auf dem Client dekomprimieren.
Eben. Dann hab ich ja deine bisherigen Hinweise zu _diesem_ Thema ausnahmsweise verstanden. Obwohl der Provider, mit dem ich es bei meinem "Projekt" zu tun habe, durchaus entgegenkommend ist, kann ich da nicht einfach was am Server rumbasteln - wäre ja noch schöner. Ich kann sein Serverangebot bis an alle möglichen Grenzen ausnutzen, aber nicht ändern.
Wenn ich also was machen will, was der Server nicht kann, muß ich versuchen, eine clientseitige Lösung zu finden. Und das isz ziemlich erbärmlich.Auch gzip_cnc arbeitet ja auf dem Server - wenngleich nicht als Modul, sondern als CGI-Skript über die Apache-eigene Handler-Einbindungs-Schnittstelle.
Der Server, mit dem ich es hier zu tun habe, ist kein Apache, sondern IIS.
Grüße aus Berlin
Christoph S.
-
Hallo Christoph,
Der Server, mit dem ich es hier zu tun habe, ist kein Apache, sondern IIS.
Dann muss du nur noch ASP lernen und du kannst damit alles machen was du beabsichtigst.
Grüße
ThomasPS: OK, es _war_ irnonisch, aber irgendwie stimmt das doch ;-)
-
hi ;-)
Der Server, mit dem ich es hier zu tun habe, ist kein Apache, sondern IIS.
Dann muss du nur noch ASP lernen und du kannst damit alles machen was du beabsichtigst.Ich _kann_ ja (beinahe) ASP. Finde ich sogar gar nicht so verkehrt, seit ich herausgefunden habe, daß ich gar nicht gezwungen bin, dafür VBScript einzusetzen.
Ich _will_ bloß nicht. Hatte mir aus irgendeinem Grund in den Kopf gesetzt, daß es mit Includes besser und leichter gehen müßteGrüße aus Berlin
Christoph S.
-
-
Hi Christoph,
Ich kann sein Serverangebot bis an alle möglichen Grenzen ausnutzen, aber nicht ändern.
Und wo genau sind diese Grenzen?
gzip gibt es als binary auch für Windows. Serverseitige Anwendungen kannst Du ausführen. Du kannst also HTML-Dateien komprimieren. Wieviel fehlt dann noch - Negotiation kann der IIS doch, oder?
Wenn ich also was machen will, was der Server nicht kann, muß ich versuchen, eine clientseitige Lösung zu finden. Und das ist ziemlich erbärmlich.
Im Falle der Komprimierung ist es schlicht unmöglich - es sei denn, Du stellst alle komprimierten Dateien schon clientseitig her und lädst den gesamten Baum mit beiden Versionen per FTP hoch.
Deshalb versuche ich, Deine serverseitigen Möglichkeiten exakt auszuloten. Wir sind allerdings nicht mehr weit von dem Punkt entfernt, wo Du einen anderen Provider erwägen solltest ... denn technisch ist das Problem ja auch mit dem IIS durchaus lösbar.
Der Server, mit dem ich es hier zu tun habe, ist kein Apache, sondern IIS.
Deshalb habe ich gzip_cnc nicht explizit vorgeschlagen, sondern nur als Beispiel erwähnt.
Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.-
hi,
gzip gibt es als binary auch für Windows. Serverseitige Anwendungen kannst Du ausführen. Du kannst also HTML-Dateien komprimieren. Wieviel fehlt dann noch - Negotiation kann der IIS doch, oder?
Prinzipiell ja.
Wenn ich also was machen will, was der Server nicht kann, muß ich versuchen, eine clientseitige Lösung zu finden.
Im Falle der Komprimierung ist es schlicht unmöglich - es sei denn, Du stellst alle komprimierten Dateien schon clientseitig her und lädst den gesamten Baum mit beiden Versionen per FTP hoch.Das habe ich befürchtet. Möglicherweise wird mir nix andres übrigbleiben. Limitierender Faktor ist: ich wurde um das Erstellen einer Konzeption gebeten (für relativ viel und beständig anwachsenden Informations-Inhalt). Die "Pflege" des ferigen Projekts muß ich de facto in die Hände eines "Büro-Azubi" legen können.
Wir sind allerdings nicht mehr weit von dem Punkt entfernt, wo Du einen anderen Provider erwägen solltest
Wenn das "meine" Entscheidung wäre, wäre das längst geschehen. Es gibt aber einen auf Jahre geschlossenen Vertrag, auf den ich festgenagelt bin.
Grüße aus Berlin
Christoph S.
-
Hi Christoph,
Im Falle der Komprimierung ist es schlicht unmöglich - es sei denn, Du stellst alle komprimierten Dateien schon clientseitig her und lädst den gesamten Baum mit beiden Versionen per FTP hoch.
Das habe ich befürchtet. Möglicherweise wird mir nix andres übrigbleiben. Limitierender Faktor ist: ich wurde um das Erstellen einer Konzeption gebeten (für relativ viel und beständig anwachsenden Informations-Inhalt). Die "Pflege" des ferigen Projekts muß ich de facto in die Hände eines "Büro-Azubi" legen können.Der braucht aber auf dem Client-Rechner nur Deine Batch-Datei anklicken, die über Deinen ganzen Baum rennt und komprimiert, was zu komprimieren ist. Abschließend nimmt er den WinCommander und synchronisiert den Baum gegen den Server - fertig.
Du kannst es natürlich auch _komfortabel_ machen und den FTP-Synchronisierer selbst schreiben - dann merkt der Azubi gar nicht, daß er nicht _nur_ die von ihm geänderten Dateien hoch lädt, sondern daß das von ihm gestartete Programm vorher daraus zusätzlich noch andere Dateien herstellt ...
Gerade in Deiner Situation mache ich mich lieber von ein paar Seiten eigenem Quelltext abhängig als von einem unflexiblen Provider und dessen Features.
Und wenn das nebenbei auch noch die für den Server performantere Lösung ist ... on-the-fly-Berechnungen versuche zu vermeiden, wenn ich mit derselben Abstraktionsmöglichkeit das Ganze auch in produktionsarmen Zeiten (oder auf anderen Maschinen) automatisieren kann.Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
-
-
Hallo Michael,
Wieviel fehlt dann noch - Negotiation kann der IIS doch, oder?
Wieviel Sinnlosigkeit damit man bereiben kann zeigt Opera wunderbar
[pref:t=36900&m=202219]Und Apache auch. (ich werde mitten meine unschuldige Klickerei in der Apache 2 Doku, tatsächlich auf deutsche Seiten umgeleitet, die 1. ich nicht lesen will, 2. auch wenn ich es wollte, nicht könnte, weil die Seiten unleserlich sind.
Irgendwie sinkt in letzer Zeit meine Sympathie rapide für ContentNegoatation.
Grüße
Thomas
-
-
-
-
-
-
-
-
-
-
Hallo Christoph,
In SELFHTML gibts eine sehr kurz gefaßte Erläuterung dazu, aber die Übersicht ist leider nicht nur kurz, sondern auch unvollständig.
Nicht ganz korrekt mag ja sein, (file und virtual sind ganz umgekehrt erklärt) aber das da was fehlen würde? OK, wenn du meinst, dass dort die konditionale Abfragen für SSI nicht beschrieben werden: hast recht.
für den IIS habe ich noch nix gefunden, auch in der MSDN nicht (hallo Bio ;-)), möglicherweise hab ich in der MSDN aber auch nicht alles durchsucht. Daher weiß ich nicht genau, was der IIS _prinzipiell_ bereitstellt.
Schwer zu glauben, ich habe _nur_ nach SSI bei M$ gesurcht: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iisref/html/psdk/asp/serv9i5h.asp
So, und jetzt drei Nachfragen:
<div id="name">
<!--#include file="datei.htm" -->
</div>
Und da gehts dann los. Mein Apache weigert sich, ein HTML-Dokument einzubinden, obwohl ich exakt so verfahren bin, wie in der Apache-Dokumentation beschrieben.Blöde frage: kennt dein Apache htm überhaupt? Hast du auch mit html statt htm versucht?
Hat jemand eine Erklärung dafür?
Ne.
Und dann: Meine HTML-Dokumente haben alle eine DOCTYPE-Angabe, zwei meta-tags, einen Header-Bereich usw. Das heißt, ich habe unter Umständen mehrere Dutzend (immer dieselben) DOCTYPE-Angaben, die bereits auf dem Server in einer "großen" Datei zusammengeklebt werden und auch so beim Browser ankommen,
Das finde ich ziemlich arg, ersten weiis keiner wie die versch. Browser wirklich reagieren: also kann sein dass letztlich gar nichts angezeigt wird, unangehmen aber ist vor allem, dass damit massenweise unnötige Daten übertragen werden.
und obs valide wäre, mochte ich gar nicht erst testen. Natürlich könnte ich das alles rausstreichen, ... aber dann sind die Einzelseiten nicht mehr valide und ich kann mich nicht mehr leiden.
Verstehe ich das richtig? Du möchtest nicht, dass bei dir einzelne Dateien nicht valide sind und deshalb produzierst du lieber sehr große nicht valide Dateien? Habe ich was missverstanden? ;-)
Das einzige, was mir bisher eingefallen ist, wäre, sämtliche HTML-Dokumente vor dem Includieren erst durch ein Perl-Script aufrufen zu lassen, das die "überflüssigen" Auszeichnungen entfernt. Hat jemand ne bessere Idee?
Nicht wirklich.
zweitens:
Jetzt möchte ich aber in (mindestens) eins meiner DIV's ein XML-Dokument reinschubsen. Geht zwar prinzipiell auch, aber da gibts Unterscheide bei den Servern. Mein Apache möchte es gerne in der Form
<!--#include virtual="daten.xml" -->
haben, dann gehts prima. Aber der IIS bei meinem Provider zeigt da gar nix an, der möchte zwingend
<!--#include file="daten.xml" -->Du könntest eine konditionale SSI abfrage schreiben: also Servertyp abfragen und ja nachdem den <!--# include --> setzen.
»»Bleibt mir wirklich nix andres übrig als mit einer "if"-Abfrage über "SERVER_SOFTWARE" den grade aktiven Server zu ermitteln?
Ehm... genau!
Und dann ergibt sich ein ähnliches Problem für die "Kopfdaten" wie bei den HTML-Dokumenten.
Da wirst du auch nicht viel machen können. Ich zweifle daran, dass es helfen würde wenn du dein xml ebenfalls als ein zu parsende Datei ausgeben würdest: "AddHandler server-parsed .xml"
drittens:
Macht das überhaupt Sinn, aich so eine "SSI-Konstruktion" auszudenken? ... angezeigten Gesamtdatei schnell mal eine Größe von 1 MB und mehr erreichen kann.Was ... ne, ich frage lieber erst gar nicht nach, wobe es so wichtig ist das alles zusammen bleibt und dass man dazu 1MB große Datei herunterladen müsste.
Ich hoffe, ich hab mein augenblickliches "Problem" einigermaßen verständlich dargestellt.
Durchaus, aber ich sehen keine SSI Lösung, wenn du nicht bereit bist die zu inkludierende Datein als HTML-snipplest zu erstellen und sie so einzufügen.
Grüße
Thomas-
hi,
ich habe _nur_ nach SSI bei M$ gesurcht: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iisref/html/psdk/asp/serv9i5h.asp
Ich sagte ja, daß ich möglicherweise nicht alles ...
Blöde frage: kennt dein Apache htm überhaupt? Hast du auch mit html statt htm versucht?
ja, das kann er ;-)
Verstehe ich das richtig? Du möchtest nicht, dass bei dir einzelne Dateien nicht valide sind und deshalb produzierst du lieber sehr große nicht valide Dateien? Habe ich was missverstanden? ;-)
Nein, das verstehst du nicht richtig. Die "Einzeldateien" sind valide (lege ich sehr großen Wert drauf). Aber die "große" Datei wird eben gerade dadurch nicht valide
»»Bleibt mir wirklich nix andres übrig als mit einer "if"-Abfrage über "SERVER_SOFTWARE" den grade aktiven Server zu ermitteln?
Ehm... genau!Schade ...
Da wirst du auch nicht viel machen können. Ich zweifle daran, dass es helfen würde wenn du dein xml ebenfalls als ein zu parsende Datei ausgeben würdest: "AddHandler server-parsed .xml"
Du zweifelst mit Recht. Ich habs durchgespielt.
Allerdings ist mir das mit XML wichtig - man macht ja solche Tests nicht immer ganz freiwillig. Der Hintergrund ist, daß ich einem "Kunden" ein relativ großes Projekt, das nahezu täglich neue Inhalte dazu bekommt, erstellen soll. Die Sekretärin kann Schreibmaschine, muß aber die (fast) tägliche Tipparbeit erledigen ...
Ich kann ihr noch beibringen, daß sie in
<titel>
...</titel>
jeweils die überschrift eines neuen Artikels, und in
<text>
...
</text>
einfach bloß den zu tippenden Text reinschreiben soll. Mehr geht nicht.Was ... ne, ich frage lieber erst gar nicht nach, wobe es so wichtig ist das alles zusammen bleibt und dass man dazu 1MB große Datei herunterladen müsste.
Daß alles zusammenbleibt, ist enorm wichtig, daß es es aber 1 MB werden muß (oder noch mehr) ist absolut unerwünscht
ich sehen keine SSI Lösung, wenn du nicht bereit bist die zu inkludierende Datein als HTML-snipplest zu erstellen und sie so einzufügen.
Naja, ich dachte, ich könnte mir etwas Arbeit ersparen. Prinzipiell bin ich zwar bereit dazu, Schnipsel zu erstellen, aber das bedeutet, daß ich von jedem validen HTML-Dokument noch eine "invalide" Kopie in Form eines Codeschnipsels erstellen muß :-(
Grüße aus Berlin
Christoph S.
-
Hi Thomas,
OK, wenn du meinst, dass dort die konditionale Abfragen für SSI nicht beschrieben werden: hast recht.
nicht wirklich - weil es diese "in SSI" nicht gibt. Auch hier noch mal die NCSA-Seite:
http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html_Das_ ist ein Apache-eigenes XSSI-Element.
Die Unterscheidung zwischen SSI und XSSI war meines Wissens in der Apache-Dokumentation früher mal deutlicher zu erkennen (es gibt sogar Google-Hits in Dokumenten, in denen XSSI jetzt nicht mehr zu finden ist). Noch heute finden sich Spuren davon z. B. in
http://httpd.apache.org/docs/misc/custom_errordocs.htmlUnd da gehts dann los. Mein Apache weigert sich, ein HTML-Dokument einzubinden, obwohl ich exakt so verfahren bin, wie in der Apache-Dokumentation beschrieben.
Blöde frage: kennt dein Apache htm überhaupt? Hast du auch mit html statt htm versucht?Um den Inhalt einer Datei einzubinden, muß der Apache nichts "kennen".
Schlimmstenfalls wird dabei halt der konfigurierte Default-MIME-Type geliefert (den gibt es immer).Du könntest eine konditionale SSI abfrage schreiben: also Servertyp abfragen und ja nachdem den <!--# include --> setzen.
Das wird auf dem IIS schwierig, weil es XSSI wäre.
»»Bleibt mir wirklich nix andres übrig als mit einer "if"-Abfrage über "SERVER_SOFTWARE" den grade aktiven Server zu ermitteln?
Und das genauso. "if" ist eine Apache-Erfindung.
Durchaus, aber ich sehen keine SSI Lösung, wenn du nicht bereit bist die zu inkludierende Datein als HTML-snipplest zu erstellen und sie so einzufügen.
Dem schließe ich mich an (wobei ich dies selbst praktiziere).
Die Alternative wäre halt, alles per Programm statisch zu generieren (wie meine
http://www.schroepl.net/projekte/mod_gzip/
-Seiten, die auf meinem PC hier SSI, aber auf dem Server nur noch statisches HTML sind).Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.-
Hallo Michael,
Noch heute finden sich Spuren davon z. B. in
http://httpd.apache.org/docs/misc/custom_errordocs.htmlDie ist auch noch bei der Doc für den 2-er dabei:
http://httpd.apache.org/docs-2.0/misc/custom_errordocs.html
Wobei in beiden nur das betont wird, dass man mit XSSI (und da setzen sie selbst einen Link auf die mode_include-Seite) und mit ErrorDocument halt schöne customisierte Fehlermeldungen erzeugen kann. Wie auch immer ... du hast wohl recht, dass es unter IIS nicht gehen wird.Grüße
Thomas
-
-