Entering content frame

Function documentation HTTP Browser Tracing Locate the document in its SAP Library structure

Use

To analyze the dynamic behavior of your coding, you can use HTTP browser tracing as an alternative to ICM Tracing.

To do this, install an http proxy tool locally on your computer, which you can then use to trace all HTTP traffic between the browser and the server.

Note

There are different HTTP proxy tools.We do not recommend a specific HTTP proxy tool from any provider. You choose which tool you will use.

Note the license conditions of the tool you select.

Prerequisites

You have installed an HTTP proxy tool on your computer.

Example

Note

Since HTTP proxy tracing for the Web Dynpro for ABAP and the BSP program model have similar functions, an HTTP trace analysis is explained below using the example of a BSP application.

Create a small test program, such as:

<%@page language="ABAP"%>

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

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

    <input type=submit>

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

Start your test program in the browser, perform the user authentication and then enter a value in the input field. The roundtrip is started when you click on the button.

This is how the HTTP trace looks (this is an extract and has been edited):

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

The browser was started and an http request was sent to the server. The trace contains a lot of useful information.

The first line of the HTTP request is always in the format HTTP verb (usually GET or POST), URL, and the HTTP protocol used (HTTP/1.0 or HTTP/1.1).For the GET verb, all parameters (form fields) are specified as part of the URL using the delimiters ? and &. The parameters are placed in the HTTP body for the POST verb. The URL is always an absolute URL. Even if relative URLs are used in the HTML document, the browser changes them into absolute URLs to retrieve them.

The Accept header lists all types of responses that the browser can understand.This list is always completed by the wildcard */* (accept everything).

The Accept-Language header is very important. This header mirrors the browser’s language settings. It lists the languages that the user specified as possible languages. SAP Web AS will use these languages to perform the logon in the required language.

The User-Agent header identifies the browser. This header is often employed during the rendering to compensate for the small differences in HTML that the different browsers can understand.

The Host header represents the host name that was used originally within the URL.The GET line only lists the absolute URL and does not represent the host name. This information is stored in the Host header.

Caution

Note that this host name does not absolutely have to be the correct host name, but is merely the name with which you addressed the server.

Note

Note that in this small example, the entire HTTP communication runs over one connection. In complex browsers, the browser can open several connections, however, and can send several requests in parallel. The server notes which HTTP request comes from which connection, and sends the HTTP response over the correct connection.
You should therefore always use the connection number so that HTTP requests can be mapped to responses in the trace.

The server replies with an 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>

The first line in the HTTP response is important. It contains the HTTP protocol that is used by the server, the HTTP return code and a string with a descriptive text. The server usually (but not always) answers with exactly the same protocol that the browser requested. The server can also “switch down” the HTTP protocol that is used. The HTTP return code is very important. In this example it is 401, which means that the server rejected the request and requires authentication.

Content-Length and Content-Type describe the utilization.

The WWW-Authenticate header is used with HTTP 401 responses only. It informs the browser which string (server identification) should be displayed in the authentication popup that requests the user name and password.

There then follows a blank line, and then the response body.

Note

Note that the authentication response has an HTML body. The browser only represents this HTML if the authentication popup is cancelled.

Once you have entered a user name and password, the browser submits the same request again.

  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

In this case, the additional authentication header is useful. You can see that basic authentication is used. Then follow the coded user name and password. This information is only coded, it is not encrypted.

The HTTP response has return code 302, which means that the requested URL is not available. The new destination is specified in the Location header. You can recognize the BSP runtime URL mangling process here. URL mangling is carried out so that additional information can be coded in the URL.

There is also a Set-Cookie header. SSO2 is configured and active on this server. The server implements an SSO2 cookie in the root path for the complete domain. This means that for each new HTTP request to any other URL on a different server in our domain, an SSO2 cookie is sent together with the request. If the new sever has a relationship of trust with the server that sent the SSO2 cookie, then it will accept the HTTP request without additional authentication queries. This costs a few hundred additional bytes per request.

Once the browser has received a new location as the access target, it triggers a GET request to this location and receives the expected page.

  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
  

  <html><body><form method="POST">
    <input type=text name="test" value="">
    <input type=submit>
  </form></body></html>

You can see a Cookie header in the HTTP request. (This cookie is supplied to the browser by the Set-Cookie header and is returned by the browser with the Cookie header.) Note that with this cookie, the values for the previous path and the domains that were used when the cookie was set are not forwarded to the server. The browser used this information to find out that the cookie goes with the request, and then sent the cookie.

The HTTP response is answered with return code 200 OK. This is a normal response that can be displayed. The BSP runtime similarly sets a cookie, although this is placed in a path that is intended for this BSP application.

The BSP runtime also adds three new headers to the HTTP response to inform the browser and all HTTP proxies that they should not cache this HTTP response.

You can see the HTML of the test page in the HTTP response’s capacity.This is displayed by the browser.

 

In an additional HTTP request/response cycle, enter the value “abc” in the input field and press the 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

  

  <html><body><form method="POST">
    <input type=text name="test" value="abc">
    <input type=submit>
  </form></body></html>

The HTTP request now uses the POST verb (as specified in the HTML <form> element). For the POST, the current form Field (the value of the input field) is written to the body of the request after a blank line. These values are always written as “name=value”.

A new header, Referer, has been added. This header comes from the browser and identifies the server that triggered the HTTP request. The Referer is very useful for Web sites in order to find out from which other sites a Web site is accessed. This header is also very controversial, however.For example, you can use a search engine with a certain number of keywords and then click on a link. The Referer now becomes the search engine: Part of its URL contains the keywords that were used to find this link. Web sites can assess this Referer header to find out which type of keywords attracts the most users. This is why many firewall and proxy tools have techniques for deleting these headers from the HTTP request.

The Cookie header now contains both cookies (in a Header field).

No additional cookies are set in the HTTP response. The server found out that the browser already has all relevant cookies and will not set them again. Here you can recognize the asymmetrical behavior of cookies.They are sent to the browser with a Set Cookie header in the HTTP response only, including information about the path and domain. Afterwards, cookies are only sent from the browser to the server using the Cookie header in the HTTP-request, but without any domain or path information.

The body of the response now contains the newly rendered HTML coding.The input field contains the value “abc” that was just entered.

 

 

Leaving content frame