HTTP-Browser-Tracing (SAP-Bibliothek - Business Server Pages Administration)

HTTP-Browser-Tracing

Verwendung

Um das dynamische Verhalten Ihres Codings zu analysieren können Sie alternativ zum ICM-Tracing das HTTP-Browser-Tracing verwenden.

Dazu installieren Sie ein HTTP-Proxy-Tool lokal auf Ihrem Computer. Mit solch einem Tool können Sie dann einfach den gesamten HTTP-Verkehr zwischen dem Browser und dem Server verfolgen.

Hinweis

Es gibt unterschiedliche HTTP-Proxy-Tools. Wir empfehlen kein bestimmtes HTTP-Proxy-Tool eines bestimmten Anbieters. Welches Tool Sie verwenden, hängt von Ihnen ab.

Beachten Sie die Lizenzbedingungen des von Ihnen gewählten Tools.

Voraussetzungen

Sie haben ein HTTP-Proxy-Tool auf Ihrem Computer installiert.

Beispiel

Hinweis

Da das HTTP-Proxy-Tracing für das Web Dynpro für ABAP und das BSP-Programmiermodell analog funktioniert, wird die Analyse eines HTTP-Traces im Folgenden am Beispiel einer BSP-Anwendung erläutert.

Erstellen Sie ein kleines Testprogramm, z.B.

<%@page language="ABAP"%>

  <html><body><form method="POST">

    <input type=text name="test" value="<%=test%>">

    <input type=submit>

  </form></body></html>

Starten Sie Ihr Testprogramm im Browser, führen Sie die Benutzerauthentifizierung durch und geben Sie einen Wert in das Eingabefeld ein. Beim Klicken auf den Button wird die Rundreise gestartet.

Und so sieht dann der HTTP-Trace aus (auszugsweise und editiert):

Connection: 1 -- HTTP Request received from browser 365 bytes
  GET /sap/bc/bsp/sap/bcm00/helloworld.htm HTTP/1.1
  Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
  Accept-Language: en-us,de;q=0.5
  User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
  Host: ld0020.wdf.sap.corp:50021

Zuerst wurde der Browser gestartet und ein HTTP-Request wurde an den Server gesendet. Hierbei sind schon viele interessante Informationen im Trace enthalten.

Die erste Zeile des HTTP-Requests ist immer in der Form HTTP Verb (meistens GET oder POST), URL, und verwendetes HTTP-Protokoll (HTTP/1.0 oder HTTP/1.1). Für das GET Verb warden alle Parameter (form fields) als Teil der URL unter Verwendung der Abgrenzungszeichen ? und & mitgegeben. Für das POST Verb werden die Parameter in den HTTP-Body platziert. Die URL ist immer eine absolute URL. Selbst wenn im HTML-Dokument relative URLs verwendet werden, ändert der Browser diese in absolute URLs ab, um sie zu retrieven.

Der Accept-Header listet alle Arten von Antworten auf, die der Browser verstehen kann. Diese Liste wird immer durch das Wildcard */* abgeschlossen (accept everything).

Der Accept-Language-Header ist sehr wichtig. Dieser Header spiegelt die Spracheinstellungen des Browsers wider. In diesem Header sind die Sprachen aufgelistet, die der Benutzer als mögliche Sprachen spezifiziert hat. Der SAP Web AS wird auf diese Sprachen zurückgreifen, um eine Anmeldung in der gewünschten Sprache durchzuführen.

Der User-Agent-Header identifiziert den Browser. Dieser Header wird oft während des Renderings eingesetzt, um die kleinen Unterschiede in HTML, die die verschiedenen Browser verstehen können, zu kompensieren.

Der Host-Header stellt den Hostnamen dar, der ursprünglich innerhalb der URL verwendet wurde. Die GET-Zeile listet ja nur die absolute URL auf und stellt nicht den Hostnamen dar. Diese Information ist im Host-Header abgelegt.

Achtung

Beachten Sie, dass dieser Hostname nicht unbedingt der korrekte Hostname sein muss, sondern lediglich der Name ist, mit dem Sie den Server adressiert haben.

Hinweis

Beachten Sie, dass in diesem kleinen Beispiel die gesamte HTTP-Kommunikation über eine Verbindung läuft. In komplexen Programmen kann der Browser jedoch mehrere Verbindungen öffnen und mehrere Requests parallel abschicken. Der Server merkt sich, welcher HTTP-Request von welcher Verbindung stammt und sendet die HTTP-Response über die korrekte Verbindung.
Verwenden Sie daher immer die Verbindungsnummer, um HTTP-Requests auf Responses im Trace abzubilden.

Der Server antwortet mit einer HTTP-Response.

Connection: 1 -- HTTP Response from ld0020.wdf.sap.corp 1960 bytes
  HTTP/1.1 401 Unauthorized
  Content-Length: 1718
  Content-Type: text/html; charset=iso-8859-1
  WWW-Authenticate: Basic realm="SAP Web Application Server [B20]"

  <html>
  <head><title>Logon Error Message</title></head>
  <body>....Error message: Logon failed....</body>
  </html>

In der HTTP-Response ist wieder die erste Zeile wichtig. Darin ist das vom Server eingesetzte HTTP-Protokoll enthalten, der HTTP-Returncode und ein String mit einem beschreibenden Text. Normalerweise antwortet der Server mit genau demselben Protokoll, das der Browser angefordert hat, aber nicht immer. Der Server kann auch das verwendete HTTP-Protokoll “herunterschalten”. Der HTTP-Returncode ist sehr wichtig. Im vorliegenden Beispiel ist er 401, d.h. der Server hat den Request abgelehnt und benötigt eine Authentifizierung.

Content-Length und Content-Type beschreiben die Auslastung.

Der WWW-Authenticate-Header wird nur bei HTTP-401-Responses verwendet. Er teilt dem Browser mit, welcher String (Server-Identifikation) im Authentifizierungs-Popup bei der Abfrage nach Benutzernamen und Kennwort ausgegeben werden soll.

Es folgt eine Leerzeile und danach der Body der Response.

Hinweis

Beachten Sie, dass die Authentifizierungs-Response einen HTML-Body besitzt. Der Browser stellt dieses HTML nur dann dar, wenn das Authentifizierungs-Popup mit Abbrechen verlassen wird.

Nachdem Sie einen Benutzernamen und ein Kennwort eingegeben haben, submittet der Browser wieder den gleichen Request.

  Connection: 1 -- HTTP Request received from browser 412 bytes
  GET /sap/bc/bsp/sap/bcm00/helloworld.htm HTTP/1.1
  Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
  Accept-Language: en-us,de;q=0.5
  User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
  Host: ld0020.wdf.sap.corp:50021
  Authorization: Basic T25lIFR3byBUaHJlZTpGb3VyIEZpdmUgU2l4

  Connection: 1 -- HTTP Response from ld0020.wdf.sap.corp 899 bytes
  HTTP/1.1 302 Moved temporarily
  Location: /sap(bD1lbiZjPTAwMA==)/bc/bsp/sap/bcm00/helloworld.htm
  Set-Cookie: MYSAPSSO2=AjEx...tggN5w%3d%3d; path=/; domain=wdf.sap.corp
  Content-Length: 25
  Content-Type: text/html

Hier ist der zusätzliche Authentifizierungs-Header interessant. Hier kann man sehen, dass Basic Authentication verwendet wird. Danach folgen kodiert Benutzername und Kennwort. Diese Informationen sind nicht verschlüsselt, nur kodiert.

Die HTTP-Response hat den Returncode 302, was bedeutet, dass die angeforderte URL nicht verfügbar ist. Die neue Destination wird im Location-Header spezifiziert. Hier können Sie den URL-Mangling-Prozess der BSP-Laufzeit erkennen. Das URL-Mangling wird vorgenommen, um zusätzliche Informationen in der URL zu kodieren.

Zusätzlich gibt es noch einen Set-Cookie-Header. Auf diesem Server ist SSO2 konfiguriert und aktiv. Der Server setzt ein SSO2-Cookie im Root-Pfad für die komplette Domäne. Dies bedeutet, dass für jeden neuen HTTP-Request an irgend eine andere URL an einem anderen Server in unserer Domäne ein SSO2-Cookie mit dem Request zusammen gesendet wird. Wenn der neue Server ein Vertrauensverhältnis mit dem Server besitzt, der das SSO2-Cookie hinausgeschickt hat, dann wird er den HTTP-Request ohne weitere Authentifizierungsabfrage akzeptieren. Dies kostet einige hundert zusätzliche Bytes pro Request.

Nachdem nun der Browser eine neue Lokation als Zugriffsziel bekommen hat, feuert er einen GET-Request an diese Lokation ab und erhält die erwartete Seite.

  Connection: 1 -- HTTP Request received from browser 1033 bytes
  GET /sap(bD1lbiZjPTAwMA==)/bc/bsp/sap/bcm00/helloworld.htm HTTP/1.1
  Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
  Accept-Language: en-us,de;q=0.5
  User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
  Host: ld0020.wdf.sap.corp:50021
  Cookie: MYSAPSSO2=AjEx...tggN5w%3d%3d

  Connection: 1 -- HTTP Response from ld0020.wdf.sap.corp 501 bytes
  HTTP/1.1 200 OK
  Set-Cookie: sap-appcontext=c2Fw...4tQVRU; path=/sap(bD1lbiZjPTAwMA==)/bc/bsp/sap/bcm00/
  Content-Length: 123
  Content-Type: text/html; charset=iso-8859-1
  Expires: 0
  Pragma: no-cache
  Cache-Control: no-cache

Im HTTP-Request ist ein Cookie-Header zu sehen. (Dieses Cookie wird dem Browser über den Set-Cookie-Header geliefert und wird vom Browser mit dem Cookie-Header zurückgegeben.) Beachten Sie bei diesem Cookie, dass die Werte für den früheren Pfad und die Domäne, die beim Setzen des Cookie verwendet wurden, nicht an den Server weitergeleitet werden. Der Browser hat mit diesen Informationen herausgefunden, dass das Cookie zu dem Request passt und hat dann das Cookie gesendet.

Die HTTP-Response wird mit dem Returncode 200 OK beantwortet. Dies ist eine normale Antwort, die ausgegeben werden kann. Die BSP-Laufzeit setzt ebenfalls ein Cookie, aber auf einem Pfad, der für diese BSP-Anwendung vorgesehen ist.

Zusätzlich fügt die BSP-Laufzeit drei neue Header der HTTP-Response hinzu, um dem Browser und allen HTTP-Proxies mitzuteilen, dass sie diese HTTP-Response nicht cachen sollen.

In der Nutzlast der HTTP-Response können Sie das HTML der Testseite sehen. Dies wird vom Browser zur Anzeige gebracht.

In einem weiteren HTTP-Request/Response-Zyklus geben Sie den Wert “abc” in das Eingabefeld ein und drücken Sie den Button.

  Connection: 1 -- HTTP Request received from browser 1358 bytes
  POST /sap(bD1lbiZjPTAwMA==)/bc/bsp/sap/bcm00/helloworld.htm HTTP/1.1
  Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
  Referer: http://ld0020.wdf.sap.corp:50021/sap(bD1lbiZjPTAwMA==)/bc/bsp/sap/bcm00/helloworld.htm
  Accept-Language: en-us,de;q=0.5
  Content-Type: application/x-www-form-urlencoded
  Content-Length: 8
  User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
  Host: ld0020.wdf.sap.corp:50021
  Cookie: sap-appcontext=c2FwL…tQVRU; MYSAPSSO2=AjEx..tggN5w%3d%3d

test=abc

  Connection: 1 -- HTTP Response from ld0020.wdf.sap.corp 312 bytes
  HTTP/1.1 200 OK
  Content-Length: 126
  Content-Type: text/html; charset=iso-8859-1
  Expires: 0
  Pragma: no-cache
  Cache-Control: no-cache

Der HTTP-Request verwendet nun das POST Verb (so wie es im HTML <form> Element angegeben war). Für das POST wird das aktuelle Form Field (der Wert des Eingabefeldes), in den Body des Requests nach einer leeren Zeile geschrieben. Diese Werte werden immer in der Form “name=value” geschrieben.

Ein neuer Header, Referer, ist neu hinzugekommen. Dieser Header kommt vom Browser und bezeichnet den Server, der den HTTP-Request ausgelöst hat. Referer ist sehr interessant für Websites, um herauszufinden, von welchen anderen Sites aus Zugriffe stattfinden. Er ist jedoch auch sehr kontrovers. Beispielsweise können Sie eine Suchmaschine mit einer bestimmten Anzahl von Schlüsselworten verwenden und dann auf einen Link klicken. Nun wäre der Referer die Suchmaschine. Ein Teil seiner URL enthält die Schlüsselworte, die verwendet wurden, um diesen Link zu finden. Websites können diesen Referer-Header auswerten, um herauszufinden, welche Art von Schlüsselworten die meisten Benutzer anlockt. Daher haben viele Firewall- und Proxy-Tools eine Technik, um diesen Header vom HTTP-Request zu entfernen.

Der Cookie-Header enthält nun die beiden Cookies (in einem Header-Feld).

Im HTTP-Response werden keine weiteren Cookies gesetzt. Der Server hat herausgefunden, dass der Browser bereits alle relevanten Cookies besitzt und wird sie nicht erneut setzen. Hier ist das asymmetrische Verhalten von Cookies zu erkennen. Sie werden nur in der HTTP-Response zum Browser mit einem Set-Cookie-Header geschickt, inklusive Pfad- und Domänenangabe. Danach werden Cookies nur noch vom Browser zum Server geschickt, unter Verwendung des Cookie-Headers im HTTP-Request, aber ohne jegliche Domänen- oder Pfadangaben..

Im Body der Response ist nun das neue gerenderte HTML-Coding. Das Eingabefeld hat den vorhin eingegebenen Wert “abc”.