nicht angemeldet
(HTTP) Wie heißt der Webserver zu einer URL?
Hi,
ich habe mir (inspiriert durch einen link checker, der das auch konnte) ein kleines Perl-Programm geschrieben, welches zu einer beliebigen URL den Namen des entsprechenden Webservers feststellen kann.
Ich habe hier auch eine CGI-Version - vielleicht will Stefan die mal als Dienst auf www.teamone.de installieren (HTML-Formular dazu ist trivial, aber auch vorhanden). Das könnte man beispielsweise in den .htaccess-Artikel einbauen und den Leser erst mal checken lassen, ob sein Provider einen Apache-Webserver hat ...
Die Superminikurzversion zum Testen:
#-------------------------------------------------
use LWP::Simple;
#-------------------------------------------------
my $url = "http://hier_servername_eintragen";
Bei mir wird der über CGI gelesen und die
Ausgabe in HTML formatiert
#-------------------------------------------------
Document-Head zur URL lesen - da steht auch der Server-Name drin
my ($mimetype, $size, $modified, $expires, $server) = LWP::Simple::head ($url);
#-------------------------------------------------
print "Der Server der URL '$url' identifiziert sich als '$server'\n"; }
#-------------------------------------------------
Mit ActivePerl 5.005 unter Windows NT4 funktioniert das auch tadellos (egal ob in dieser CGI-Variante oder als Standalone-Perl-Programm mit eingebrannter URL etc.).
Mit Perl 5.004 unter IBM AIX funktioniert es *nicht*. Ich bekomme immer eine leere Antwort in allen fünf Feldern von "head" zurück.
Um überhaupt LWP:Simple auf meiner UNIX-Kiste verwenden zu können (was *nicht* in der normalen Perl5.004-Auslieferung enthalten ist, mußte ich mir vorher aus CPAN einen Haufen Module holen:
- MIME-Base64 V2.11
- URI V1.03
- HTML-Parser V2.23
- libnet V1.0606
- Digest-MD5 V2.08
- libwww-perl V5.44
Fragt mich nicht, wieso - das Installationsverfahren über "make" findet entsprechende Abhängigkeiten und fordert das ganze andere Zeug (in dieser Reihenfolge) als Vorbedingung für libwww-perl, wo dann endlich LWP:Simple drin ist.
Die Versionsnummern sind jeweils die neuesten, die ich (vor ein paar Wochen) bei CPAN gefunden hatte.
LWP an sich funktioniert - jedenfalls haben wir ein CGI-Skript mit LWP::Simple::get zum "Absaugen" einer URL erfolgreich laufen lassen.
Das obige Program selbst ist unter Perl5.004 nach "perl -c" durchaus "OK" und liefert keinerlei Fehlermeldungen - nur eben auch kein Ergebnis.
Hat jemand eine Ahnung,
a) wieso das Skript mit UNIX-Perl5.004 plus der genannten Module nicht funktioniert, oder
b) wo ich für die UNIX-Schiene eine Perl-Auslieferung bekommen kann, die an Vollständigkeit mit dem (beeindruckenden) ActivePerl-Paket mithalten kann?
Ich will mir ja nicht für jedes Skript wieder fünf weitere CPAN-Module installieren - gegen tausend Stück auf einmal hätte ich aber keine Bedenken ... Und vor allem möchte ich auf beiden Plattformen dieselbe "Ausbaustufe" von Perl haben.
Eigentlich müßten die Module ja doch als Perl-Quelltexte vorliegen. Dann könnte ich sie vielleicht einfach von einem Rechner auf den anderen übertragen.
Andererseits ruft das CPAN-Installationprogramm über "make" manchmal den C-Compiler auf - wozu das überhaupt?
Grübelgrübel ...
Vielleicht können ein paar Perl-Benutzer unter UNIX mal ausprobieren, ob das Skript bei ihnen läuft und welche Perl-"Ausbaustufe" sie dafür verwenden? (Cheatah? Frank Schönmann? Stefan - falls er es anbieten will?)
Bei mir liefert "perl -v" die Version "5.004_01". Ich habe mal versucht, mir 5.005 zu holen, die ließ sich bei mir aber nicht übersetzen ... :-(
-
Hm, wenn auf dem Unix netcat installiert ist, versuch doch mal folgendes:
system (' echo "HEAD / HTTP/1.0
" netcat www.server.de 80 grep Server');
Ansonsten kannst du das gleiche mit IO::Socket machen. Auf meiner Homepage ist dazu nen Beispielprogramm. Nennt sich Servertest.
-
Hm, wenn auf dem Unix netcat installiert ist ...
Leider nein.
Ansonsten kannst du das gleiche mit IO::Socket machen. Auf meiner Homepage ist dazu nen Beispielprogramm. Nennt sich Servertest.
Hm. Download von Deiner Seite produziert eine Datei "servertest-1.1.tar.gz" der Grö0e 1766 Bytes.
GNU-unzip meint dazu aber:
"gunzip: servertest-1_1_tar.gz: invalid compressed data--crc error".
Binär übertragen habe ich sie. Und nun?-
Hm, wenn auf dem Unix netcat installiert ist ...
Leider nein.Ansonsten kannst du das gleiche mit IO::Socket machen. Auf meiner Homepage ist dazu nen Beispielprogramm. Nennt sich Servertest.
Hm. Download von Deiner Seite produziert eine Datei "servertest-1.1.tar.gz" der Grö0e 1766 Bytes.
GNU-unzip meint dazu aber:
"gunzip: servertest-1_1_tar.gz: invalid compressed data--crc error".
Binär übertragen habe ich sie. Und nun?Hm, sollte ne Größe von 1762 haben. Was solls, ich schick sie dir mal per Mail. Oder gib mal tar zxvf servertest-1.1.tar.gz ein.
-
Hm, wenn auf dem Unix netcat installiert ist ...
Leider nein.Ansonsten kannst du das gleiche mit IO::Socket machen. Auf meiner Homepage ist dazu nen Beispielprogramm. Nennt sich Servertest.
Hm. Download von Deiner Seite produziert eine Datei "servertest-1.1.tar.gz" der Grö0e 1766 Bytes.
GNU-unzip meint dazu aber:
"gunzip: servertest-1_1_tar.gz: invalid compressed data--crc error".
Binär übertragen habe ich sie. Und nun?Hm, sollte ne Größe von 1762 haben. Was solls, ich schick sie dir mal per Mail. Oder gib mal tar zxvf servertest-1.1.tar.gz ein.
Hallo Eric,
Habe gerade dein tool heruntergeladen, und wollte dich fragen, was für werte sollte ein Intel P233 MXX haben ?
Was hälst du von folgender Ausgabe:
Servertest wurde gestartet. Dauer 30 Sekunden.
Auswertung für Server: http://localhost/
Der Server wurde auf Port 80 angesprochen.
Der Test wurde um 21:16 Uhr und 8 Sekunden gestartet,
und wurde um 21:16 Uhr und 38 Sekunden beendet.
Folgende Dokumente wurden dabei immer wieder von dem Server abgerufen:index.html
Dabei wurde der Server von 10 Prozessen gleichzeitig kontaktiert.
Anzahl der Seiten, die der Server zurückgeschickt hat: 3334
Gesamtauer des Tests: 30 Sekuden
Im Durchschnitt lieferte der Server 111.13 Seiten pro Sekunde zurück.Oder auf einem P133:
Servertest wurde gestartet. Dauer 30 Sekunden.
Auswertung für Server: http://localhost/
Der Server wurde auf Port 80 angesprochen.
Der Test wurde um 20:14 Uhr und 43 Sekunden
gestartet,
und wurde um 20:15 Uhr und 15 Sekunden beendet.
Folgende Dokumente wurden dabei immer wieder von dem Server
abgerufen:index.html
Dabei wurde der Server von 10 Prozessen
gleichzeitig kontaktiert.
Anzahl der Seiten, die der Server zurückgeschickt hat: 1618
Gesamtauer des Tests: 30 Sekuden
Im Durchschnitt lieferte der Server 53.93 Seiten pro Sekunde zurück.Was für eine Maschiene war deine? Und wie kann man einen Screenshot, unter X-Window machen, und abspeichern ?
thx!
andy alias anonymous
-
Hallo Eric,
Erik, aber ich hab sogar Schulzeugnisse, wo Eric drauf steht.
Habe gerade dein tool heruntergeladen, und wollte dich fragen, was für werte sollte ein Intel P233 MXX haben ?
Was hälst du von folgender Ausgabe:
Servertest wurde gestartet. Dauer 30 Sekunden.
Auswertung für Server: http://localhost/
Der Server wurde auf Port 80 angesprochen.
Der Test wurde um 21:16 Uhr und 8 Sekunden gestartet,
und wurde um 21:16 Uhr und 38 Sekunden beendet.
Folgende Dokumente wurden dabei immer wieder von dem Server abgerufen:index.html
Dabei wurde der Server von 10 Prozessen gleichzeitig kontaktiert.
Anzahl der Seiten, die der Server zurückgeschickt hat: 3334
Gesamtauer des Tests: 30 Sekuden
Im Durchschnitt lieferte der Server 111.13 Seiten pro Sekunde zurück.Hm, hab ich noch nicht getestet.
Oder auf einem P133:
Servertest wurde gestartet. Dauer 30 Sekunden.
Auswertung für Server: http://localhost/
Der Server wurde auf Port 80 angesprochen.
Der Test wurde um 20:14 Uhr und 43 Sekunden
gestartet,
und wurde um 20:15 Uhr und 15 Sekunden beendet.
Folgende Dokumente wurden dabei immer wieder von dem Server
abgerufen:index.html
Dabei wurde der Server von 10 Prozessen
gleichzeitig kontaktiert.
Anzahl der Seiten, die der Server zurückgeschickt hat: 1618
Gesamtauer des Tests: 30 Sekuden
Im Durchschnitt lieferte der Server 53.93 Seiten pro Sekunde zurück.Naja, ich hab auf nem 3 Jahre alten P90 80 Seiten / Sekunde gemacht. Sogar mit CGI hab ich paarundfünfzig gemacht. Die Maschiene war aber ziemlich getuned, und der Test lief ueber Stunden. Nebenbei hatte ich 300 Clientprozesse.
Was für eine Maschiene war deine? Und wie kann man einen Screenshot, unter X-Window machen, und abspeichern ?
Da hat KDE nen nettes Tool.
thx!
andy alias anonymous
Ach ja, bitte Webserver und Tool auf verschiedenen Rechnern laufen lassen, da das Tool auch ziemlich viel an Leistung verbrät. Ich hab es auf nem PII-300 mit 300 Prozessen laufen lassen. Der Server war nen P90.
Ach und nochwas, bitte vorher nachfragen, bevor du testest, ich hatte mir damit mal den eigenen Server lahmgelegt. Nicht etwa, weil die Maschiene abgesemmelt ist, sondern, weil ich dann nen 700 MB-Logfile hatte, das die Platte zu gemacht hatte.
-
Hallo Eric,
Erik, aber ich hab sogar Schulzeugnisse, wo Eric drauf steht.
Ups, sorry das war keine Absicht!
Habe gerade dein tool heruntergeladen, und wollte dich fragen, was für werte sollte ein Intel P233 MXX haben ?
Was hälst du von folgender Ausgabe:
Servertest wurde gestartet. Dauer 30 Sekunden.
Auswertung für Server: http://localhost/
Der Server wurde auf Port 80 angesprochen.
Der Test wurde um 21:16 Uhr und 8 Sekunden gestartet,
und wurde um 21:16 Uhr und 38 Sekunden beendet.
Folgende Dokumente wurden dabei immer wieder von dem Server abgerufen:index.html
Dabei wurde der Server von 10 Prozessen gleichzeitig kontaktiert.
Anzahl der Seiten, die der Server zurückgeschickt hat: 3334
Gesamtauer des Tests: 30 Sekuden
Im Durchschnitt lieferte der Server 111.13 Seiten pro Sekunde zurück.Hm, hab ich noch nicht getestet.
Oder auf einem P133:
Servertest wurde gestartet. Dauer 30 Sekunden.
Auswertung für Server: http://localhost/
Der Server wurde auf Port 80 angesprochen.
Der Test wurde um 20:14 Uhr und 43 Sekunden
gestartet,
und wurde um 20:15 Uhr und 15 Sekunden beendet.
Folgende Dokumente wurden dabei immer wieder von dem Server
abgerufen:index.html
Dabei wurde der Server von 10 Prozessen
gleichzeitig kontaktiert.
Anzahl der Seiten, die der Server zurückgeschickt hat: 1618
Gesamtauer des Tests: 30 Sekuden
Im Durchschnitt lieferte der Server 53.93 Seiten pro Sekunde zurück.Naja, ich hab auf nem 3 Jahre alten P90 80 Seiten / Sekunde gemacht. Sogar mit CGI hab ich paarundfünfzig gemacht. Die Maschiene war aber ziemlich getuned, und der Test lief ueber Stunden. Nebenbei hatte ich 300 Clientprozesse.
Was für eine Maschiene war deine? Und wie kann man einen Screenshot, unter X-Window machen, und abspeichern ?
Da hat KDE nen nettes Tool.
Muss ich mir mal Reinziehen!
thx!
andy alias anonymous
Ach ja, bitte Webserver und Tool auf verschiedenen Rechnern laufen lassen, da das Tool auch ziemlich viel an Leistung verbrät. Ich hab es auf nem PII-300 mit 300 Prozessen laufen lassen. Der Server war nen P90.
Ach und nochwas, bitte vorher nachfragen, bevor du testest, ich hatte mir damit mal den eigenen Server lahmgelegt. Nicht etwa, weil die Maschiene abgesemmelt ist, sondern, weil ich dann nen 700 MB-Logfile hatte, das die Platte zu gemacht hatte.
Wen soll ich denn fragen, wenn der Server mir gehört ?!? ;) Ausserdem habe ich das tool aus dem /tmp gestartet, dieses Verzeichnis ist bei mir eine seperate Partition, da kann nicht viel schiefgehen!
thx a lot!
andy
-
Ausserdem habe ich das tool aus dem /tmp gestartet, dieses Verzeichnis ist bei mir eine seperate Partition, da kann nicht viel schiefgehen!
Doch, weil der Startort des Tools völlig egal ist für das Überlaufen des Dateisystems, in dem der getestete Webserver seine Log-Dateien anlegt.
-
Ausserdem habe ich das tool aus dem /tmp gestartet, dieses Verzeichnis ist bei mir eine seperate Partition, da kann nicht viel schiefgehen!
Doch, weil der Startort des Tools völlig egal ist für das Überlaufen des Dateisystems, in dem der getestete Webserver seine Log-Dateien anlegt.
Jep, das einzigste, was da hilft, ist /usr/local/apache/logs auf ne extra-Partition (wird bei größeren Servern oft gemacht, wegen der Performance), oder einfach Disk-Quoata. Das sollte auch helfen.
-
Ausserdem habe ich das tool aus dem /tmp gestartet, dieses Verzeichnis ist bei mir eine seperate Partition, da kann nicht viel schiefgehen!
Doch, weil der Startort des Tools völlig egal ist für das Überlaufen des Dateisystems, in dem der getestete Webserver seine Log-Dateien anlegt.
Jep, das einzigste, was da hilft, ist /usr/local/apache/logs auf ne extra-Partition (wird bei größeren Servern oft gemacht, wegen der Performance), oder einfach Disk-Quoata. Das sollte auch helfen.
Ups... das ist auch wieder war!
Naja, meine logfiles liegen allesamt in /var/logs/httpd/, und auch dort habe ich eine seperate partition! (Glück gehabt!)
-
-
-
-
Was hälst du von folgender Ausgabe:
Dabei wurde der Server von 10 Prozessen gleichzeitig kontaktiert.
Anzahl der Seiten, die der Server zurückgeschickt hat: 3334
Gesamtauer des Tests: 30 Sekuden
Im Durchschnitt lieferte der Server 111.13 Seiten pro Sekunde zurück.Ich habe gerade mit ebenfalls 10 Prozessen aus einem Pentium III / 450 (128 MB RAM) gerade mal müde 48 Seiten/sec herausgeholt (Apache 1.3.2) und bin nun ziemlich verblüfft, wieso der so schlecht ist.
Als ich 30 Prozesse versucht habe, brach mir der anrufende UNIX-Rechner (von ca. 1993) auseinander (fork() gescheitert usw.) - ich versuche gerade, eine größere Kiste dafür zu requirieren :-(Erik, an welchen Schrauben drehst Du, wenn Du die Performance eines Webservers erhöhen willst?
-
-
-
-
-
-
Hallo Michael
Ich habe hier auch eine CGI-Version - vielleicht will Stefan die mal als Dienst auf www.teamone.de installieren (HTML-Formular dazu ist trivial, aber auch vorhanden).
Ist eigentlich gar keine schlechte Idee. Als "standalone"-Idee vielleicht etwas schwer unterzubringen. Was ich mir aber vorstellen koennte, waere so eine Art Rubrik "Kleine Online-Helferlein" auf den Aktuell-Seiten, in der ein ganzes Set solcher kleiner, nuetzlichen Online-Utility-Scripts versammelt ist. Vielleicht koennte man dazu auch die Rubrik "Statistik" entsprechend umaendern, und schon haette man bereits zwei von den kleinen Utilities. Na, mal sehen, Idee ist jedenfalls gebongt!
Sag mal, kann man mit so einem remote-call via LWP::Simple eigentlich auch auf Umgebungsvariablen des fernen Servers zugreifen? Dann koennte man ja noch mehr Daten rausbekommen.
viele Gruesse
Stefan Muenz-
Sag mal, kann man mit so einem remote-call via LWP::Simple eigentlich auch auf Umgebungsvariablen des fernen Servers zugreifen? Dann koennte man ja noch mehr Daten rausbekommen.
So tief bin ich in den LWP-Modul noch nicht eingestiegen - Du siehst ja, daß bei mir nicht mal die Dreizeiler zuverlässig funktionieren ... :-(
Läuft mein Skript eigentlich auf Deinem Server? (Wenn nicht, müßtest Du klären, wie das mit der Installation von CPAN-Modulen bei Dir aussehen würde ...)
-
Hallo Michael
Ich habe hier auch eine CGI-Version - vielleicht will Stefan die mal als Dienst auf www.teamone.de installieren (HTML-Formular dazu ist trivial, aber auch vorhanden).
Ist eigentlich gar keine schlechte Idee. Als "standalone"-Idee vielleicht etwas schwer unterzubringen. Was ich mir aber vorstellen koennte, waere so eine Art Rubrik "Kleine Online-Helferlein" auf den Aktuell-Seiten, in der ein ganzes Set solcher kleiner, nuetzlichen Online-Utility-Scripts versammelt ist. Vielleicht koennte man dazu auch die Rubrik "Statistik" entsprechend umaendern, und schon haette man bereits zwei von den kleinen Utilities. Na, mal sehen, Idee ist jedenfalls gebongt!
Schau dir doch mal http://www.netcraft.com/survey/ an. Da gibt es nette Infos. Und nebenbei kann man herausfinden, welches OS, und welchen Server irgendein Webserver im Ineternet benutzt. Geb doch mal homepages.msn.com ein.
Wenn es z. B. um das OS von anderen Servern wie z. B. Mailservern geht, oder FTP-Servern, sollte man sich mal http://www.insecure.org/ anschauen. Dort findet man nen Tool, names Nmap, mit dem man das OS von vielen Servern herausfinden kann. Weis leider nur nicht, wie legal das ist.
Sag mal, kann man mit so einem remote-call via LWP::Simple eigentlich auch auf Umgebungsvariablen des fernen Servers zugreifen? Dann koennte man ja noch mehr Daten rausbekommen.
Hm, bei nem HEAD / HTTP/1.0 schickt nen 1.3.9er Apachi folgende Daten mit:
HTTP/1.1 200 OK
Date: Mon, 23 Aug 1999 18:58:55 GMT
Server: Apache/1.3.9 (Unix) PHP/3.0.12 mod_fastcgi/2.2.2 mod_ssl/2.4.0 OpenSSL/0.9.3a
Connection: close
Content-Type: text/htmlAlso, Datum, und natürlich Server mit Zusatzmodulen. Viel mehr kann man ihm nicht entlocken.
-
Schau dir doch mal http://www.netcraft.com/survey/ an. Da gibt es nette Infos. Und nebenbei kann man herausfinden, welches OS, und welchen Server irgendein Webserver im Ineternet benutzt. Geb doch mal homepages.msn.com ein.
Kenne ich, war auch Teil meiner Motivation, das selbst zu bauen.
Hm, bei nem HEAD / HTTP/1.0 schickt nen 1.3.9er Apachi folgende Daten mit:
Hoppla - 1.3.9, und ich weiß nichts davon? Ein Skandal ist das :-) - ich dachte, ich bin auf deren Mailing-Liste für neue Versionen ...
HTTP/1.1 200 OK
Date: Mon, 23 Aug 1999 18:58:55 GMT
Server: Apache/1.3.9 (Unix) PHP/3.0.12 mod_fastcgi/2.2.2 mod_ssl/2.4.0 OpenSSL/0.9.3a
Connection: close
Content-Type: text/htmlSo ähnlich sieht das bei mir auch aus, nachdem ich Dein "servertest.pl" entsprechend zurechtgelöscht habe. *Das* funktioniert bei mir also - vielen Dank! (Hmpf - was habe ich da bloß für ein verschimmeltes LWP::Simple???)
Also, Datum, und natürlich Server mit Zusatzmodulen. Viel mehr kann man ihm nicht entlocken.
Klar, wir machen ja auch kein CGI auf deren Server (dann wüßten wir fast alles).
Den Umfang dieser Ausgabe kann man übrigens in der Webserver-Konfiguration (des Apache) als Webmaster selbst beeinflussen:
ServerTokens directive
Syntax: ServerTokens MinimalOSFull
Default: ServerTokens Full
Context: server config
Status: core
Compatibility: ServerTokens is only available in Apache 1.3 and laterThis directive controls whether Server response header field which is sent back to clients includes a description of
the generic OS-type of the server as well as information about compiled-in modules.ServerTokens Min[imal]
Server sends (e.g.): Server: Apache/1.3.0
ServerTokens OS
Server sends (e.g.): Server: Apache/1.3.0 (Unix)
ServerTokens Full (or not specified)
Server sends (e.g.): Server: Apache/1.3.0 (Unix) PHP/3.0 MyMod/1.2This setting applies to the entire server, and cannot be enabled or disabled on a virtualhost-by-virtualhost basis.
Erfreulicherweise ist der Default-Wert "full", aber ein "schweigsamer" Webmaster kann hier "den Hahn zudrehen" ...
-
Schau dir doch mal http://www.netcraft.com/survey/ an. Da gibt es nette Infos. Und nebenbei kann man herausfinden, welches OS, und welchen Server irgendein Webserver im Ineternet benutzt. Geb doch mal homepages.msn.com ein.
Kenne ich, war auch Teil meiner Motivation, das selbst zu bauen.
Hm, bei nem HEAD / HTTP/1.0 schickt nen 1.3.9er Apachi folgende Daten mit:
Hoppla - 1.3.9, und ich weiß nichts davon? Ein Skandal ist das :-) - ich dachte, ich bin auf deren Mailing-Liste für neue Versionen ...
Hm, das kann etwas dauern.
HTTP/1.1 200 OK
Date: Mon, 23 Aug 1999 18:58:55 GMT
Server: Apache/1.3.9 (Unix) PHP/3.0.12 mod_fastcgi/2.2.2 mod_ssl/2.4.0 OpenSSL/0.9.3a
Connection: close
Content-Type: text/htmlSo ähnlich sieht das bei mir auch aus, nachdem ich Dein "servertest.pl" entsprechend zurechtgelöscht habe. *Das* funktioniert bei mir also - vielen Dank! (Hmpf - was habe ich da bloß für ein verschimmeltes LWP::Simple???)
Ich denke, IO::Socket ist da besser, damit kann man alles machen. FTP, HTTP, POP3, SMTP....
Also, Datum, und natürlich Server mit Zusatzmodulen. Viel mehr kann man ihm nicht entlocken.
Klar, wir machen ja auch kein CGI auf deren Server (dann wüßten wir fast alles).
Hm, die nächste Möglichkeit, was über nen Server herauszufinden, wäre nen Portscan. Aber ich bin mir nicht sicher, wie legal der ist. Dann weis man aber eigendlich so ziemlich alles.
-
(Hmpf - was habe ich da bloß für ein verschimmeltes LWP::Simple???)
Ich denke, IO::Socket ist da besser, damit kann man alles machen. FTP, HTTP, POP3, SMTP...."Besser" ist relativ. Mit LWP::Simple war die Sache ein Zweizeiler. Das, was ich inzwischen aus Deinem Skript durch entsprechende Anpassung gebaut habe, hat fast 200 Zeilen bekommen ... (ich kommentiere halt ziemlich geschwätig)
Andere Frage: Das Server-Abfragen funktioniert
jetzt prima. Wenn der abgefragte Server lebt!Und wenn nicht? Dann fällt mir irgendwann die CGI-Anwendung auseinander, weil *mein* Server seinen timeout erreicht. Überhaupt will ich gar nicht so lange warten, sondern lieber aktiv aufhören, wenn die Antwort nicht ruck-zuck kommt.
Ich habe hier im Büro eine HTML-Datei mit einer Liste alle mir bekannten Webserver, und ich wollte nun über SSI-EXEC das Skript zur Abfrage der Webserver-Identität in jeden Absatz dieser Liste einfügen. Dann bekäme ich eine "selbstwartende" Auflistung aller bei uns eingesetzten Webserver (das sind ziemlich viele, oioioi) und ganz nebenbei noch einen online-Test für all diese Server.
Im jetzigen Zustand funktioniert das aber nicht.Deshalb meine Frage: Kann ich über IO::socket angeben, daß mein TCP-Zugriffsversuch nur z. B. 3 Sekunden laufen und dann aufgeben soll? Oder bin ich da absolut vom Zeitverhalten des Gegenübers abhängig?
-
Andere Frage: Das Server-Abfragen funktioniert
jetzt prima. Wenn der abgefragte Server lebt!Und wenn nicht? Dann fällt mir irgendwann die CGI-Anwendung auseinander, weil *mein* Server seinen timeout erreicht. Überhaupt will ich gar nicht so lange warten, sondern lieber aktiv aufhören, wenn die Antwort nicht ruck-zuck kommt.
Ich habe hier im Büro eine HTML-Datei mit einer Liste alle mir bekannten Webserver, und ich wollte nun über SSI-EXEC das Skript zur Abfrage der Webserver-Identität in jeden Absatz dieser Liste einfügen. Dann bekäme ich eine "selbstwartende" Auflistung aller bei uns eingesetzten Webserver (das sind ziemlich viele, oioioi) und ganz nebenbei noch einen online-Test für all diese Server.
Im jetzigen Zustand funktioniert das aber nicht.Deshalb meine Frage: Kann ich über IO::socket angeben, daß mein TCP-Zugriffsversuch nur z. B. 3 Sekunden laufen und dann aufgeben soll? Oder bin ich da absolut vom Zeitverhalten des Gegenübers abhängig?
Hm, ja, kann man beim verbinden mit angeben. Das genaue Parameter sollte in man IO::Socket oder in man perlipc zu finden sein. Wenn du es nicht findest, sag bescheid, ich schau mal nach. Aber 3 Sekunden ist zu Hard. Wenn, dann 10 Sekunden. Es kann ja sein, dass noch nen ISDN-Router oder so was dazwischen ist. Wenn es mehere Server sind, bringt es was, die Sache mit meheren Prozessen zu machen. Dann werden mehere gleichzeitig abgefragt.
-
Deshalb meine Frage: Kann ich über IO::socket angeben, daß mein TCP-Zugriffsversuch nur z. B. 3 Sekunden laufen und dann aufgeben soll? Oder bin ich da absolut vom Zeitverhalten des Gegenübers abhängig?
Ich habe in der Perl-Doku nur die drei Parameter gefunden, die Du auch verwendest.
Aber 3 Sekunden ist zu Hard. Wenn, dann 10 Sekunden. Es kann ja sein, dass noch nen ISDN-Router oder so was dazwischen ist.
Bei mir geht es nur um ein Intranet, da ist nichts mehr Störendes dazwischen.
Aber das HTML-Dokument enthält jetzt etwa 20 dieser SSI-EXEC-Aufrufe (eben die mir bekannten Büro-Webserver), von denen momentan etwa drei auf den timeout laufen und die Ausgabe des restlichen Dokuments behindern - und irgendwann gibt dann halt mein Webserver auch auf ...-
Deshalb meine Frage: Kann ich über IO::socket angeben, daß mein TCP-Zugriffsversuch nur z. B. 3 Sekunden laufen und dann aufgeben soll? Oder bin ich da absolut vom Zeitverhalten des Gegenübers abhängig?
Ich habe in der Perl-Doku nur die drei Parameter gefunden, die Du auch verwendest.
Aber 3 Sekunden ist zu Hard. Wenn, dann 10 Sekunden. Es kann ja sein, dass noch nen ISDN-Router oder so was dazwischen ist.
Bei mir geht es nur um ein Intranet, da ist nichts mehr Störendes dazwischen.
Aber das HTML-Dokument enthält jetzt etwa 20 dieser SSI-EXEC-Aufrufe (eben die mir bekannten Büro-Webserver), von denen momentan etwa drei auf den timeout laufen und die Ausgabe des restlichen Dokuments behindern - und irgendwann gibt dann halt mein Webserver auch auf ...Die Variable heißt Timeout. Der Timeout wird glaube ich in Sekunden angegeben. Steht in man IO::Socket
-
-
-
-
-
-
-
Hi,
Sag mal, kann man mit so einem remote-call via LWP::Simple eigentlich auch auf Umgebungsvariablen des fernen Servers zugreifen? Dann koennte man ja noch mehr Daten rausbekommen.
LWP::Simple macht eigentlich nichts anderes, als eine Seite anzufordern - wie es ein Browser auch tut. Mehr kriegt man damit also auch nicht raus.
Nebenbei: Bei mir funktioniert funktioniert das Script einwandfrei, Perl-Version ist 5.00404 (LWP standardmäßig installiert). Nebenbei habe ich erfahren, daß ich auf meinem Server auch Frontpage Extensions nutzen könnte... aber wer will das schon? :-)
Cheatah
-
Hi,
Sag mal, kann man mit so einem remote-call via LWP::Simple eigentlich auch auf Umgebungsvariablen des fernen Servers zugreifen? Dann koennte man ja noch mehr Daten rausbekommen.
LWP::Simple macht eigentlich nichts anderes, als eine Seite anzufordern - wie es ein Browser auch tut. Mehr kriegt man damit also auch nicht raus.
Ja, klar. Der Server schickt da einiges mit. Es gibt sogar ein paar Server, die schicken eine sogenannte MD5-Checksum mit. Da kannst du sogar überprüfen, ob die Seite, z. B. durch nen Proxy verändert wurde. Mann muss einfach mal versuchen, die Seite per Telnet abzurufen. Dann siehst du alles. Ist wirklich interessant.
-
-
-
Hi,
Mit Perl 5.004 unter IBM AIX funktioniert es *nicht*. Ich bekomme immer eine leere Antwort in allen fünf Feldern von "head" zurück.
mir fällt gerade ein: Liegt vielleicht ein Proxy dazwischen? Dann kannst Du AFAIK LWP::Simple nicht mehr verwenden, dafür aber LWP::UserAgent. Frag mich aber bitte nicht, wie man die Routine umschreiben muß, LWP habe ich bisher kaum benutzt *g*
Cheatah
-
Mit Perl 5.004 unter IBM AIX funktioniert es *nicht*. Ich bekomme immer eine leere Antwort in allen fünf Feldern von "head" zurück.
mir fällt gerade ein: Liegt vielleicht ein Proxy dazwischen?Nein. Beim ersten Test waren Abfragerechner und abgesprochener Webserverrechner sogar identisch (AIX), beim zweiten Test habe ich den Webserver auf dem PC daneben angesprochen.
Umgekehrt vom PC aus auf die AIX-Kiste geht es - deshalb suche ich die Schuld bei den unterschiedlichen Perl-Interpretern.
-