HTTP
Funktion | Testen Sie eine beliebige RFC-URL (HTTP, HTTPS usw.) |
---|---|
Alarmierend | Antwortcode, Verbindungszeit, Übertragungszeit, Inhaltsübereinstimmungen, gültiges Zertifikat |
HTTP-Details
HTTP-Parameter
Parameter | Beschreibung |
---|---|
URL | RFC-URL (HTTP, HTTPS usw.) |
Nutzername | Geben Sie einen Benutzernamen ein, falls die URL eine Authentifizierung erfordert. Um zu testen, ob eine Webseite den Benutzernamen und das Passwort akzeptiert, wie sie in den spezifischen Feldern der SKOOR Engine sind, geben Sie die URL wie folgt ein: |
Passwort | Geben Sie ein Passwort ein, falls die URL eine Authentifizierung erfordert. |
Methode | Wählen Sie eine der folgenden Anfragemethoden aus: ERHALTEN (Standard) Wenn entweder PUT oder POST ausgewählt ist, wird ein zusätzliches Datentextfeld aktiviert. |
Daten | Nur sichtbar, wenn entweder PUT- oder POST- Methode ausgewählt ist. Ermöglicht die Eingabe des Hauptteils der PUT/POST-Anforderung. |
Authentifizierung | Wählen Sie einen der folgenden Authentifizierungstypen aus: Beliebig (von libcurl ausgewählt) (Standard) |
Proxy-Adresse | Es ist möglich, eine URL über einen Proxy zu testen. Wenn dieses Feld verwendet wird, geht die Anfrage über den Proxy. Anders als bei normalen HTTP-Requests geht in diese Messung der Zeitpunkt des Verbindungsaufbaus zum Proxy ein. Die Gesamtzeit einschließlich Website-Download ist schneller, wenn sie auf dem Proxy zwischengespeichert wird. |
Proxy-Port | Proxy-Portnummer |
Proxy-Benutzername | Geben Sie den Proxy-Benutzernamen ein |
Proxy-Passwort | Geben Sie das Proxy-Passwort ein |
Proxy-Authentifizierung | Wählen Sie den Authentifizierungstyp für den Proxy aus. Siehe Authentifizierungsparameter oben. |
Auszeit | Timeout in Sekunden (Standard ist 120 s), bevor mit einem Warnstatus geantwortet wird, dass die Webseite nicht verfügbar ist |
Inhaltsprüfung | Überprüfen Sie den Textinhalt im heruntergeladenen Dokument. Reguläre Ausdrücke werden unterstützt. |
Weiterleitungen folgen | Aktivieren Sie dieses Kontrollkästchen, wenn Weiterleitungen gefolgt werden sollen (bis zu 50 Weiterleitungen) |
Ablauf des Zertifikats anzeigen | Aktivieren Sie dieses Kontrollkästchen, um den Ablauf des SSL-Zertifikats zu überprüfen. Dies ermöglicht die Konfiguration von Alarmgrenzen für eine bestimmte Anzahl von Tagen, bevor Zertifikate ablaufen. |
Verbindungszeit unterdrücken | Wenn eines dieser Kontrollkästchen aktiviert ist, wird die Verbindungszeit und/oder Übertragungszeit jeder Überprüfung nicht in der Datenbank gespeichert und ihre Werte sind nicht mehr im Wertebereich sichtbar. Ihr Wert steht auch nicht mehr zur Verwendung in Alarm Limit zur Verfügung. |
SSL/TLS-Version | Wählen Sie aus einer der folgenden Implementierungen: Standard Die Standardeinstellung hängt von der Konfiguration des Betriebssystems ab. |
Peer überprüfen | Bei HTTPS-Verbindungen kann das Server -Zertifikat mit einer auf dem Kollektor gespeicherten Zertifikatsdatei verglichen werden. Aktivieren Sie diese Option, um zu überprüfen, ob das SSL-Zertifikat des Server authentisch ist, dh ob man darauf vertrauen kann, dass der Server der ist, für den das Zertifikat steht. Wenn dieses Feld aktiviert ist, muss die korrekte Zertifikatsdatei des Server auf der SKOOR Engine gespeichert werden (siehe nächster Parameter Zertifikatsdatei ). Das gespeicherte Zertifikat wird mit dem vom Server ausgestellten Zertifikat verglichen, wenn der HTTP-Job ausgeführt wird. |
Zertifikatsdatei | Nur sichtbar, wenn der obige Parameter Verify peer auf Certificate must be authentic gesetzt ist. Geben Sie den Namen der Zertifikatsdatei (z. B. host.crt ) ein, mit der das Zertifikat des Server verglichen wird. Zertifikatsdateien müssen zuerst in das Verzeichnis /opt/eranger/ Kollektor /certificates der SKOOR Engine kopiert werden. Der Pfad kann geändert werden, indem die Variable http_cert_path in der Datei Kollektor -Kollektor.cfg bearbeitet wird. |
Host überprüfen | Nur sichtbar, wenn der obige Parameter Verify peer auf Certificate must be authentic gesetzt ist. Wählen Sie Überprüfung muss erfolgreich sein , um zu überprüfen, ob der im Zertifikat des Server angegebene allgemeine Name (CN) mit der URL des Server übereinstimmt. |
HTTP-Header | Geben Sie alle HTTP-Header ein, die SKOOR Engine mit der Anfrage senden soll. Dies ist vor allem nützlich, um die angeforderte Sprache der Webseite zu ändern oder den Benutzeragenten zu ändern, mit dem sich Agent SKOOR Engine beim Server identifiziert. Der Standardbenutzer- Agent ist: „ SKOOR Engine Monitoring Agent “, wenn dieser Header nicht definiert ist. Der Wikipedia -Link direkt neben dem Header-Textfeld führt zur Wikipedia-Seite, die alle verfügbaren HTTP-Header beschreibt. |
Inhalt in Datei speichern | Definieren Sie einen Dateinamen, in den die Ausgabe der Anfrage geschrieben wird. Tags können verwendet werden, zum Beispiel $DEVICE_ADDRESS$. Abhängig von der Endung des Dateinamens (.txt oder .html) stellt der Browser die Seite beim Klicken auf den Dateilink unterschiedlich dar. Die Angabe eines wohldefinierten Dateinamens ist praktisch, wenn die Ausgabe von einem folgenden Parsefile-Job analysiert wird. Eine Ausgabedatei mit dem Namen |
Die Dropdown-Liste Tags ermöglicht die Eingabe vordefinierter Variablen in die obigen Felder, z. B. $NAME$ für den Namen des Jobs.
Falls für eine Jobkonfiguration erforderlich, können Parameter mithilfe des URL Encode/Decode- Hilfsprogramms in der Job-Fußzeile URL-codiert oder decodiert werden:
HTTP-Werte und Alarmgrenzen
Wert / Alarm Limit | Beschreibung |
---|---|
Antwortcode | Verwenden Sie den Antwortcode des Webservers als Alarm Limit . Normal akzeptierte Rückgabecodes sind: 200 OK und 302 Gefunden Aber jeder andere Wert kann überprüft werden. Hier ist eine Liste der am häufigsten verwendeten Antwortcodes: 100 Weiter Das bedeutet, dass der Server die Anforderungsheader erhalten hat und dass der Client mit dem Senden des Anforderungshauptteils fortfahren sollte (im Fall einer Anforderung, für die ein Hauptteil gesendet werden muss, z. B. eine POST-Anforderung). Wenn der Anforderungstext groß ist, ist es ineffizient, ihn an einen Server zu senden, wenn eine Anforderung bereits aufgrund ungeeigneter Header zurückgewiesen wurde. Damit ein Server prüft, ob die Anfrage allein auf der Grundlage der Header der Anfrage angenommen werden konnte, muss ein Client in seiner ursprünglichen Anfrage als Header Expect: 100-continue senden und prüfen, ob als Antwort ein 100 Continue-Statuscode empfangen wird, bevor er fortfährt (oder 417 Expectation Failed erhalten und nicht fortfahren). 200 OK Standardantwort auf erfolgreiche HTTP-Anforderungen. 201 erstellt Die Anforderung wurde erfüllt und führte zur Erstellung einer neuen Ressource. 202 Akzeptiert Die Anfrage wurde zur Bearbeitung akzeptiert, aber die Bearbeitung wurde noch nicht abgeschlossen. Auf die Anfrage kann schließlich reagiert werden oder nicht, da sie möglicherweise nicht zugelassen wird, wenn die Verarbeitung tatsächlich stattfindet. 301 Dauerhaft umgezogen Diese und alle zukünftigen Anfragen sollten an die angegebene URL gerichtet werden 302 gefunden Dies ist der beliebteste Umleitungscode, aber auch ein Beispiel für industrielle Praxis, die dem Standard widerspricht. Die HTTP/1.0-Spezifikation erforderte, dass der Client eine temporäre Umleitung durchführte (der ursprüngliche beschreibende Ausdruck war „Moved Temporarily“), aber gängige Browser implementierten dies als 303 See Other. Daher fügte HTTP/1.1 die Statuscodes 303 und 307 hinzu, um zwischen den beiden Verhaltensweisen eindeutig zu unterscheiden. Die meisten Webanwendungen und Frameworks verwenden jedoch immer noch den Statuscode 302, als wäre es der 303. 305 Proxy verwenden (seit HTTP/1.1) Viele HTTP-Clients (wie Mozilla und IE) verarbeiten Antworten mit diesem Statuscode nicht korrekt, hauptsächlich aus Sicherheitsgründen. 307 Temporäre Umleitung In diesem Fall sollte die Anfrage mit einem anderen URI wiederholt werden, aber zukünftige Anfragen können immer noch den ursprünglichen URI verwenden. Im Gegensatz zu 303 sollte die Anfragemethode bei der erneuten Ausgabe der ursprünglichen Anfrage nicht geändert werden. Beispielsweise muss eine POST-Anforderung unter Verwendung einer anderen POST-Anforderung wiederholt werden. 400 Ungültige Anfrage Die Anfrage enthält eine falsche Syntax oder kann nicht erfüllt werden. 401 nicht Autorisiert Ähnlich wie 403 Forbidden , aber speziell für die Verwendung, wenn die Authentifizierung möglich ist, aber fehlgeschlagen ist oder noch nicht bereitgestellt wurde. 403 Verboten Die Anfrage war eine legale Anfrage, aber der Server weigert sich, darauf zu antworten. Im Gegensatz zu einer nicht autorisierten 401- Antwort macht die Authentifizierung keinen Unterschied. 404 Nicht gefunden Die angeforderte Ressource konnte nicht gefunden werden. 405-Methode nicht zulässig Eine Ressource wurde mit einer Anfragemethode angefordert, die von dieser Ressource nicht unterstützt wird; B. die Verwendung von GET in einem Formular, bei dem Daten per POST präsentiert werden müssen, oder die Verwendung von PUT in einer schreibgeschützten Ressource. 406 Nicht akzeptabel 407 Proxy-Authentifizierung erforderlich 408 Anfrage timeout Der Client konnte die Anfrage nicht fortsetzen – außer während der Wiedergabe von Adobe Flash-Videos, wo dies nur bedeutet, dass der Benutzer das Videofenster geschlossen oder zu einem anderen Video gewechselt ist. 409 Konflikt 410 Weg Gibt an, dass die angeforderte Ressource nicht mehr verfügbar ist und nicht wieder verfügbar sein wird. Dies sollte verwendet werden, wenn eine Ressource absichtlich entfernt wurde; In der Praxis wird stattdessen jedoch häufig ein 404 Not Found ausgegeben. 411 Länge erforderlich 412 Vorbedingung fehlgeschlagen 413 Anfrageeinheit zu groß 414 Anfrage-URI zu lang 415 Nicht unterstützter Medientyp 416 Angeforderter Bereich nicht erfüllbar Der Client hat einen Teil der Datei angefordert, aber der Server kann diesen Teil nicht bereitstellen (wenn der Client beispielsweise einen Teil der Datei angefordert hat, der hinter dem Ende der Datei liegt). 417 Erwartung fehlgeschlagen 421 Es bestehen zu viele Verbindungen von Ihrer Internetadresse 422 Nicht verarbeitbare Entität Die Anfrage war wohlgeformt, konnte aber aufgrund von semantischen Fehlern nicht befolgt werden. 423 Gesperrt (WebDAV) Die Ressource, auf die zugegriffen wird, ist gesperrt 424 Fehlerhafte Abhängigkeit (WebDAV) Die Anfrage ist fehlgeschlagen, weil eine vorherige Anfrage (z. B. ein PROPPATCH) fehlgeschlagen ist. 425 Ungeordnete Sammlung Definiert in Entwürfen von WebDav Advanced Collections, aber nicht vorhanden in "Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol". 426 Upgrade erforderlich Der Client sollte auf wechseln. 449 Wiederholen mit Eine Microsoft-Erweiterung: Die Anforderung sollte wiederholt werden, nachdem die entsprechende Aktion ausgeführt wurde. 500 Interner Server 501 Nicht implementiert 502 Bad Gateway 503 Dienst nicht verfügbar 504 Gateway-Zeitüberschreitung 505 HTTP-Version wird nicht unterstützt 506-Variante verhandelt auch 507 Unzureichender Speicherplatz 509 Bandbreitenlimit überschritten Dieser Statuscode wird zwar von vielen Servern verwendet, ist aber kein offizieller HTTP-Statuscode. 510 Nicht erweitert |
Verbindungszeit | Zeit bis zum Aufbau der TCP-Verbindung zum Server (in ms). SSL-Handshake wird nicht berechnet. |
Transferzeit | Zeit, bis eine Webseite bereitgestellt und die Verbindung geschlossen wird (in ms) |
Inhalt passt | Legen Sie Grenzen entsprechend der Häufigkeit fest, in der eine Zeichenfolge oder ein regulärer Ausdruck gefunden wird |
Zertifikat gültig | Die Anzahl der Tage bis zum Ablauf des Remote-SSL-Zertifikats. |
Fehlercode | Allgemeiner Job-Fehlercode (siehe Abschnitt Job-Fehlercodes ) |
HTTP-Beispiele
Beispiel 1 – Testen Sie eine Webseite
Testen Sie eine Webseite auf dem Standardport (80) und verwenden Sie das Tag $DEVICE_ADDRESS$. Auf diese Weise kann der Job oder das Gerät kopiert werden, ohne die Jobparameter selbst zu bearbeiten, nur der Jobname unterscheidet sich.
URL | http://$DEVICE_ADDRESS$ |
---|---|
Weiterleitungen folgen | Ermöglichen |